Re: [Vala] operators overload

2008-07-02 Thread Jürg Billeter
On Thu, 2008-05-15 at 02:28 -0300, Matías De la Puente wrote:
 vala, will include operators overload like in c#?

We're not planning to support operator or method overloading, however,
we might add limited support to implement operators by the use of
special interfaces, similar to how it already works for some libgee
interfaces.

Juerg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list


Re: [Vala] operators overload

2008-07-02 Thread Sam Liddicott
* Jürg Billeter wrote, On 02/07/08 13:59:
 On Thu, 2008-05-15 at 02:28 -0300, Matías De la Puente wrote:
   
 vala, will include operators overload like in c#?
 

 We're not planning to support operator or method overloading, 
are there non-technical reasons for avoiding method overloading?

I can see that where there is lots of type munging going on the concept
of overloading can get confusing, but purely within vala it seems as if
it ought not to be a problem, and as cname can be specified for external
callers where needed, the C interface won't be lacking.

It seems a shame to make vala the poor cousin to C# in this respect.

Sam
 however,
 we might add limited support to implement operators by the use of
 special interfaces, similar to how it already works for some libgee
 interfaces.

 Juerg

 ___
 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


Re: [Vala] operators overload

2008-07-02 Thread Jürg Billeter
On Wed, 2008-07-02 at 15:01 +0100, Sam Liddicott wrote:
 * Jürg Billeter wrote, On 02/07/08 14:19:
 
  There are many cases where method overloading makes code harder to read,
  as each method can do something completely different, and you have to
  look carefully at each argument type to recognize what exact method will
  be called. This is especially bad if the overloaded methods also use
  default arguments.
 
  There are certainly also legitimate use cases of method overloading,
  however, adding an additional word to the method name is seldom a
  problem and usually makes the code more, not less, readable. I consider
  code readability a very important aspect.

 
 (I realise that you may not want to draw out this discussion, that's OK)
 
 One of my problems is trying to think of different names for a set of
 functions which essentially do the same thing but with different
 arguments types

If there are no semantic differences that you can put in some words, you
can append something as simple as _with_int and _with_float. Not a lot
of effort when writing, however, might improve code readability.

 I agree that default arguments can make some if this need go away, and
 sometimes too at the expense of readability, - trying to remember which
 groups of arguments can be defaulted out together when calling and in
 the method body trying to seperate out the default arguments to try to
 work out what the caller was actually asking.

If the logic in the body heavily depends on whether you use default
expressions or not, this sounds like you should really split the
function into simpler functions.

Juerg

___
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list