Re: [Vala] Operator overloading

[Levi Bard <taktaktaktaktaktaktaktaktaktak gmail com>]

> 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.

Sure, but it's equally easy to use one of:
Vertex a = Vertex.add(b,c); // or
Vertex a = new Vertex.add(b,c);

In this case, we can even make Vertex.add() a varargs method, so that
we can have:
Vertex a = Vertex.add(b, c, d, e); // or
Vertex z = Vertex.add(someVertexArray);
rather than having to inefficiently chain a string of + operators.

> 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.

Adding a feature that is easily misused, then criticizing people for
misusing it is not a good policy.

> 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; }

I would have been equally happy with the first syntax.
I believe that the second syntax would not have been chosen if C#
hadn't used it for event handler chaining.

> > 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.

This is my point exactly.
If I have to /read/ or /modify/ a complicated algorithm, I find it
easier to have an explicit and discoverable method API.
The arithmetic expressions add a layer of confusion by playing on our
preconceived notions about arithmetic, even though their
implementations seldom hold to those notions.

-- 
http://homes.eff.org/~barlow/EconomyOfIdeas.html
http://www.dreamsongs.com/MobSoftware.html
http://www.gnu.org/philosophy/shouldbefree.html