Re: [Vala] Operator overloading

[Levi Bard <taktaktaktaktaktaktaktaktaktak gmail com>]

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

This is the reason languages have builtin primitive types. In my
opinion, it would make more sense to add complex, vector, matrix,
quaternion as native types than to add operator overloading for
user-defined types.
Additionally, you seem to be forgetting about languages (lisp) that
emphasize prefix notation for things other than method calls.

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

In my experience, code (even code to perform a purely mathematical
operation) that is written like a mathematical proof is nearly always
unreadable and unmaintainable. I primarily do "engineering work," so I
see a lot of it.

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

This is actually another reason /not/ to use arithmetic operators for
non-primitive types.
First, what is '+' for vectors? Is it elemental addition, or is it
concatenation? Not clear.
If it's elemental addition, then the += operator is horribly
inefficient, as it will create a temporary vector to store the sum of
vec_a and vec_b before assigning to vec_a.
If it's concatentation, then the += operator is once again horribly
inefficient, as it will create a temporary vector to store the
concatenation of vec_a and vec_b, when what you likely want to do is
just to append vec_a.
And in both cases, you'd better hope that vector assignment isn't
copy-on-assign!

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