Re: [Vala] Operator overloading

[alberto colombo <a colombo kingston ac uk>]

Speaking of personal preferences...

I think that operator overloading can provide much more readable code
when working with mathematical applications (complex numbers, arrays and
matrices, etc). Could it be provided in such a way that keeps
read/write-ability, without causing the technical problems listed by
James?

For example, vala could allow operators to be overloaded only as alias
of already existing functions, provided that such functions respect some
criteria (e.g., no out or ref parameters, left operand has the same type
as the return type, etc just tossing ideas). 

This would have no effects on the generated C bindings, operators could
maybe stored only in the gir files. Binding for languages that support
op overloading could automatically import them directly from the gir,
without need for name mangling.

That said, I can live without operator overloading :-)

regards
alberto

On Mon, 2009-03-23 at 18:24 -0400, A. Walton wrote:
> 2009/3/23 James Cox <jamescox84 googlemail com>:
> > I personally think operator overloading is a good feature, and that the only
> > arguments for and against it are personal preference.  There is no technical
> > reason not to include them, allowing those who like and understand operator
> > overloading to use the feature.
>
> There's an enormous technical reason. One of Vala's main goals is to
> write libraries. 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.
>
> (All of that, and I'd love to see the Vala-style generated C code for
> doing a complex math operation on a vector complete with Vala's
> copious use of side effects... man that would be nasty. :)
>
> > I think it would be a shame not to
> > implement them just because we were scare of what some programmers might do
> > with them.
>
> This is a very common software design problem, and it has been solved
> time and time again, usually the same way: If there are more occasions
> to use a feature incorrectly than correctly, you should opt on the
> side of leaving that feature out whenever possible.
>
> 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 (just read any C++ library horror
> story, they usually start with either templates or
> operator-overloading, or for the very unfortunate, both). This also
> includes C#/Vala's own usage of overloading with anonymous functions;
> unfortunately it can't realistically be fixed in Vala since it's
> trying to stay somewhat C#-like.
>
> Besides, any good IDE/editor with autocomplete can help reduce the
> typing for you in the non-overloaded case.
>
> -A. Walton
>
> > _______________________________________________
> > Vala-list mailing list
> > Vala-list gnome org
> > http://mail.gnome.org/mailman/listinfo/vala-list
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list
>
> This email has been scanned for all viruses by the MessageLabs Email
> Security System.

This email has been scanned for all viruses by the MessageLabs Email
Security System.