Re: [Vala] Operator overloading

[pancake <pancake youterm com>]

Levi Bard wrote:
> > > At the same time, by having operator overloading we can have our
> > > own implementation for any arithmetic operation over any kind of
> > > object which will make Vala a more flexible language and this will
> > > open lot of possibilities in video game programming.
> > >       
>
> This is, at best, syntax sugar. It doesn't add any flexibility to vala
> (simply calling a method named "operator+" instead of a method called
> "add"), and adds great potential for confusion. How this relates to
> video game programming is beyond me.
>
>   
Do you find more readable this code than this one?

 Complex c= new Complex(3,2);
 Complex c2= new Complex(6,3);

==>   c2 += (c * buf[i]);

==>   c2 = c2.add(Complex.multiply(buf[3], c);


it's not about calling mehot add() or calling method operator+() (which 
is an invalid method name),

it's about abstracting mathematical expressions up to APIs, It 
simplifies LOT of tasks,

Well, video game programming is just a random example, but you can just 
peek any other
example like bio-stuff, GMP, source-level packer virtual machine 
protections, static expression
evaluators, paralel programming, etc...

> > > Another nice feature would be to add an 'auto-cast' capability using
> > > code attributes over the class definitions to simplify the code writing
> > > when a cast is necessary to be done. for example:
> > >       
> > This is flexible in writing, but unreadable for the reader. To
> > understand string str = obj, the reader has to find the definition of
> > Object, search for all autocast annotations, then guess which is which.
> >     
> > > [...]
> > >       
> > The more complex the situation gets, the more difficult for the reader
> > to understand the code. Verbosity is not always bad, given that our
> > brains are not compilers.
> >     
>
> Here, I agree with Yu Feng.
> In addition, these features, while questionable by themselves, become
> nightmarish in combination.
>   
maybe i should sent them in separate mails. they dont need to be used 
together.
In reality, the only one i really find interesting and for me doesnt 
breaks readability
(well, in correct use, it enhaces the readibility, but you can always 
mess your source
if you are not using it properly,, like everything in this life). I 
agree that default-casters
can probably create confusion to the reader.

> What happens when using overloaded operators  to add a Foo and a Bar,
> both of which are implicitly castable to each other?
Nope, you have to specify that Foo has a method 'operator+' which 
overloads the
'+' operator over the Foo class agaisnt the Bar one. And allows to 
create a proxy
function for their internal values.

In game programming it's very common to use Vertex classes to store 
X,Y,Z values
and sum them in a single with Vertex a = b + c; for example (this is 
probably the
only thing i find useful and clear in C++). This is very used in OpenGL 
programming f.ex.

And giving this feature to vala we get more power than under other 
languages because
we win the possibility to define our own native operator handlers for 
different kind of
objects (or structs) and generate the proper method calls to convert a plain
arithmetic algorithm into a tree of function calls. which is something 
hard to do in most
languages (perl6 and parrot are helping this to be a more common 
functionality), but
atm if you need to do this kind of things you are forced to rewrite your 
own parser.

And Vala solves all these issues in a shot. This is why i find it useful.

> What about when
> there is a complex graph of implicitly castable types?
> Sure, it's possible to define rules for these sorts of complicated
> situations, but that means that the reader has to navigate that
> ruleset every time that code is used, and the developer has to
> renavigate that ruleset every place it's used every time any
> contiguous code changes.
>   
If the reader needs to navigate thru the source to understand such 
operator operations
is because the code is not written as it should be, because classes that 
use operator
overloading should be enought consistent by name to make the reader and 
the programmer
understand that the can be overloaded.

IMHO if you find unreadable an operator overloading, you will also find 
unreadable the
'+=' operator that is currently used to aggregate signal callbacks in 
Vala. Following your
statements to add a signal will look like:

 sig.add((a,b)=>{return a+b;});

and not:
 sig += (a,b) => { return a+b; }

> A good programming language makes it easy to create maintainable code
> and to maintain and reuse existing codebases, not just to spew out
> unreadable throwaways using a minimal number of characters.
>
>   
If i have to write a long algorithm i prefer to use arithmetic operators 
than method calls.
And i really find more useful, maintainable and readable the arithmetic 
expression rather
than an abstract call tree of functions which is far from the original 
algorithm and makes
it really harder to understand.

--pancake