Operator overloading

João Eiras joao.eiras at gmail.com
Tue Dec 18 06:52:37 PST 2007


So Peter Hall gave me the links
http://wiki.ecmascript.org/doku.php?id=discussion:operators
http://wiki.ecmascript.org/doku.php?id=proposals:operators

This indeed raises a few issues, mainly with binary operators.
I don't see a single reason for the operators not to be inherited. That
restriction is simply written in the proposal without any backup reasoning.
operators would behave exactly like regular functions. The only difference
is how they're invoked.

The only really issue is when
commutative<http://en.wikipedia.org/wiki/Commutative> operators are
used,
which could lead to ambiguities.
I'd propose for operators to be always evaluated from left to right, unless
the user specifies some kind of pragma, like a similar to the "use decimal"
one for decimal numbers. Then if the operator function is not available in
the left most member (or right most according to the pragma), it'd be looked
up on the right one. But this should only be done for commutative operators,
which are + *  ==

About "compositionality", that's not an operator issue, that's an issue
generic to the entire language. If I write two completly different unrelated
classes I can't mix both using regular member functions.

But I recognize that operators could be more problematic than benefic.

So, there are at least a few operators which implementation would somewhat
trivial.
*Being able to define the "()" (function call), "[]" (indexing) and typeof
operators is a must.*



2007/12/18, Peter Hall <peter.hall at memorphic.com>:
> This has already been proposed and rejected:
> http://wiki.ecmascript.org/doku.php?id=proposals:operators
>
> And here is some of the rationale for rejecting it:
> http://wiki.ecmascript.org/doku.php?id=discussion:operators
>
> Peter
>
>
> On Dec 17, 2007 9:04 PM, João Eiras <joao.eiras at gmail.com> wrote:
> >
> > Hi all,
> >
> > there's a feature in C++ which I like a lot, and I think it would be
> > interesting to have in es4, which is operator overloading, like
> >
> >    class X{ X& operator+(const X& x); }
> >    X a, b, c; c = a+b;
> >
> > which allows the programmer to define a sum operation between two
objects
> > of type X.
> > The notation I'm using in this e-mail is just for example.
> > C++ allows to define all operators except :: (scope resolution), .
> > (member) and .* (member through pointer)
> >
> > To keep things clean, new operators cannot be defined (like in C++),so
> >
> >    class X{ X& operator myop(const X& x); }
> >    X a, b, c; c = a myop b;
> >
> > would be invalid.
> >
> > Operators should only be defined as members of objects, so one cannot
> > right a global operator function which picks up two object (alla C++),
like
> >    function operator+:X(x:X,x:X);
> >
> > Any global operator function like this one before would be added to the
> > window, and would be equivalent to do
> > window['operator+']=function(x:X):X{}
> > because the 2nd argument would be ignored.
> >
> > The following operators should be definable:
> >   - arithmetic: +  -  *  /  %  +=  -=  *=  /=  %=  ++  --
> >   - bitwise: &  |  ^  >>  <<  >>=  <<=  ~
> >   - boolean: ||  &&  !  ||=  &&=
> >   - others: typeof  ()  []
> >
> > All these operators are binary except for |, ~ and typeof , so the left
> > hand (A) object would be the context object, and the right hand object
(B)
> > would be the argument passed to the operator member in A. For unary
> > operators, there won't be arguments, and the function would be called
upon
> > its target.
> > operator functions would only be called if the operator is explicitly
used
> > in the source code.
> >
> > Now consider an example
> >    class X{
> >      function operator+:X(x:X);
> >      function operator typeof(){ return "function";};
> >    }
> >    var a:X := new X;
> >    var b:X := new X;
> >
> >    var c:X = a + b; //sucess, operator is defined
> >
> >    a += b; //error, no += operator defined
> >
> >    var c:X = a + 1; //type-error, rhs must be of type X
> >
> >    var tp:String = typeof a;//sucess, typeof operator is ALWAYS defined,
by
> > default it works as specified
> >
> > alternative notation
> >
> >    class X{}
> >    X['operator ~'] = function(){};...
> >
> > Supporting all these operators in the spec can be somewhat awkward. So I
> > wish for at least the typeof, () and [] operators to be defined.
> > This way one can build custom collections, which have the [] indexing
> > operator.
> > Defining the () operator would fit the use case of IE and Opera (added
for
> > compatibility) which support the () operator as indexing operator in
> > NodeLists.
> >
> > What do you think ?
> >
> > Thank you for your attention.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Es4-discuss mailing list
> > Es4-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es4-discuss
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20071218/3465b731/attachment-0002.html 


More information about the Es4-discuss mailing list