Re: [Vala] Operator overloading

[John Carr <john carr unrouted co uk>]

On Mon, Mar 23, 2009 at 5:13 PM, Levi Bard
<taktaktaktaktaktaktaktaktaktak gmail com> 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.

A typical thing i used to see when modding Half-Life is the Vector
class which allows you to do vector math as though you were dealing
with simple types.

vector.x *= 5; vector.y *= 5; vector.z *= 5; becomes vector *= 5;

You can also add vectors together and so on.

It's certainly *not* something that is ground breaking and that would
bring massive improvements to the game development community. That
said, in the + vs method call case, consider vector1.add(vector2) -
does it add the vectors together and store in vector1, or does it
return a new vector. For this kind of thing, + and += have clearer and
more established intentions, i think.

> > > 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.
> What happens when using overloaded operators  to add a Foo and a Bar,
> both of which are implicitly castable to each other? 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.
>
> 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.

I'm against operator overloading in general, but wouldnt be opposed to
a limited enough subset that allowed e.g. the Vector stuff but stopped
crazy uses (C++ style omg << i << hate << that). I'm not convinced
thats possible, though...

John