Re: operator overloading syntax and methods...

Guillaume, why did you quote the "+": in teh Groovy example?

On 26 Nov 2004, at 16:05, Laforge Guillaume wrote:

> Good idea Michael!
>
> I've had a look at MSDN's site, and here is what C# does:
>
> public struct Complex
> {
>    public int real;
>    public int imaginary;
>
>    public Complex(int real, int imaginary)
>    {
>       this.real = real;
>       this.imaginary = imaginary;
>    }
>
>    public static Complex operator +(Complex c1, Complex c2)
>    {
>       return new Complex(c1.real + c2.real, c1.imaginary + 
> c2.imaginary);
>    }
>
>    //...
> }
>
> In Groovy, we could do something like that:
>
> class Complex {
>     int real, imaginary
>     Complex operator "+" (Complex c1, Complex c2) {
>         return new Complex(real: c1.real+c2.real, imaginary: 
> c1.imaginary+c2.imaginary)
>     }
> }
>
> --
> Guillaume Laforge
> http://glaforge.free.fr/weblog
>
> -----Message d'origine-----
> De : Michael Campbell [mailto:michael.campbell@...]
> Envoyé : vendredi 26 novembre 2004 16:45
> À : jsr@...
> Objet : Re: [groovy-jsr] operator overloading syntax and methods...
>
>
> I don't remember them all offhand, but c# has a nice set of method
> names for this.  Not necessarily saying we should use /those/ as such,
> but might be a nice starting point.
>
> And an added benefit is to bridge a small gap for java/c# dual-coders. 
>  =)
>
>
> On Fri, 26 Nov 2004 12:13:52 +0000, jastrachan@...
> <jastrachan@...> wrote:
>> We should be able to write code fairly cleanly to overload operators.
>>
>> How about some syntax like this..
>>
>> class Cheese {
>>
>>      String operator + (String param) {
>>         return param + " cheese!"
>>      }
>>
>>      operator [] (Object key) {
>>         // overload how we lookup items using subscript operator
>>         return key * 2
>>      }
>> }
>>
>> basically as a bit of syntax to allow the operator overloading methods
>> to be defined. Using a keyword 'operator' followed by the operator in
>> question as an alternative to using a mangled method name. It'd then
>> map to a regular method which would appear in the bytecode.
>>
>> Then we just need to figure out what the method names should be. We
>> went initially with nice simple methods in Groovy (add, subtract etc).
>> I'm wondering if its better if we mangle the names under the hood to
>> avoid clashing with legacy Java code - but use a neater syntax in
>> Groovy code. If we use a mangled Java method name at the bytecode 
>> level
>> then Java developers could add operator overloading methods to their
>> Java code.
>>
>> For a name mangling format, how about
>>
>> // this is Java code
>> public class Cheese {
>>
>>      public String _operatorAdd(String param) {
>>         return param + "cheese!";
>>      }
>> }
>>
>> Thoughts?
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
>>
>
>

James
-------
http://radio.weblogs.com/0112098/