How about lfun as a prefix? Not only for the new ones, then, but as an alternative to ´ in general:
class Foo { Foo lfun +(int x) { // or lfun::+? }
Foo lfun ´+(int x) { // (``+), perhapos +', as in +-2. :-) }
Foo lfun m_delete(int x) { // as in _m_delete } }
Or perhaps 'operator', but that would be somewhat misleading in pike.
class Foo { Foo operator *(int x) { }
Foo operator m_delete(int x) { } }
/ Per Hedbor ()
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