Ah, I did not catch on that it was an issue of renaming current LFUNs. The way I misread it, we would end up with about twice as many LFUNs, just in order to support pointers/references.
Regardless of which way we end up following in the lvalue issue, I am very much in favour of pursuing the suggested LFUN renaming scheme, with or without better suggestions for the new names.
/ Johan Sundström (folkskådare)
Previous text:
2003-04-16 14:04: Subject: Re: Pointers/lvalues
You mean the proposed more verbose lfun names? That's a separate issue; one can just as well go with ```* and `&* instead (well, the latter would require compat level stuff since two tokens `& and * can form valid pike code).
The thing with the longer lfun names was to make them more clear and at the same time allow some extensions: "this" stands for the object in which the lfun is called, and "_" for other arguments passed to it.
`! => `!this `+ => `this+_ ``+ => `_+this `-> => `this->_ `->= => `this->_=_ `() => `this() ...etc
A scheme like this would also allow separate lfuns for some operators that now are forced to share lfuns with others that aren't really the same thing:
Negation: `-this (Now calls the substraction lfun with no arguments.)
Range: `this[_.._] (Now calls `[] with two arguments, and in an expression such as x[1..] or x[..17] then the missing limits are substituted with 0 or 2147483647.)
The use of "this" and "_" was only the best we could come up with yesterday; better ideas are welcome. Anyway I think a naming scheme like the above gives more clear lfun names than the current solution with different numbers of preceding backquotes.
/ Martin Stjernholm, Roxen IS