Re: [Vala] Operator overloading

[William Swanson <swansontec gmail com>]

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

That is not true. Imagine what would happen if Vala lost support for
operators on the built-in types like int or float. Would anybody say
Vala was "equally easy to use" when even a simple expression like
"int_a + int_b" becomes "Int.add(int_a, int_b)"? The language would be
unusable. Code like "vector_a + vector_b" really IS easier to write
and comprehend than "Vector.add(vector_a,vector_b)". The question is,
are vectors and complex numbers used often enough to offset the other
disadvantages of operator overloading?

Levi Bard wrote:
> 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.

This is also untrue. The mathematical operators have precise
definitions for a variety of objects, including matrices, vectors,
complex numbers, and quaternions. Read any mathematical paper or
textbook, and you will see the same definitions used everywhere. If
someone chooses to write a * operator that behaves differently than
the mathematical convention, that operator is wrong and needs to be
fixed. This problem is not unique to operator overloading, however,
since even functions can be mis-named. Finding reasonable names for
things is just a part of programming.

A. Walton wrote:
> The only valid use case presented in this thread has been to reduce
> typing in the case of vector types, and the counter-cases of it being
> used incorrectly are staggering

Operator overloading doesn't just "reduce typing." It makes the
difference between readable math code and unreadable math code,
especially in any sort of engineering or computer graphics work. On
the other hand, it does open the door for terrible abuses as you say.
I favor John Carr's suggestion of supporting a limited subset of
operators aimed exclusively at math applications:

* / % + - ==
*= /= %= += -= !=

This would allow the important use cases such as bignums, vectors, and
complex numbers, but would limit obscenities like C++'s << operator.
For extra sanity, Vala could derive the complementary operators *= /=
%= += -= and != directly from the * / % + - and == operators. This
would make the expression "vec_a += vec_b" exactly equivalent to
"vec_a = vec_a + vec_b" in all cases, reducing abuses from that
direction. It would also make it impossible to put a += operation on
something inappropriate like a collection class, since the only way to
get the += operator is to define the + operator.

A. Walton wrote:
> Operator overloading means public symbols with
> mangled names, which are virtually unusable from C (and thusly, any
> other language save Vala). You could help this by mangling them with a
> transform like operator+()->_add(), but then you run the obvious risk
> of symbols colliding and making the C api completely unusable.

Vala solves similar problems with [CCode] directives, so solving the
problem for operator overloading shouldn't be too difficult. Alberto
Colombo also has a nice suggestion of only allowing existing named
functions to be used as operator overloads.

-William Swanson