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
Previous text:
2003-04-16 13:43: Subject: Re: Pointers/lvalues
For me it's rather the abundance of unwieldy LFUNs that make the proposal look somewhat scary, at least right now when the fog is starting to clear up a bit.
/ Johan Sundström (folkskådare)