Re: [Vala] Support for method overloading.

[Fabien CELLIER <tallion users sourceforge net>]

Hi,

IMHO overloading is a good feature for maintenance and backward
compatibility but it should follow some rules in order to avoid bad impact
in C code , for example (with convention over configuration):

vala code

void show(){...}
void show(string label){...}


C code

void show{}
void show_label{const char* label}

I know the fact that some problem begin with this name mangling but it comes
with bad practice==>
void show(){...}
void show(string label){...}
void show_label(){} //error

I'm new in vala so I'm not sure that I understand the vision but this kind
of error is a good thing, in my point of view, because it blocks bad habits
and ugly C code :).

PS:My english is awful, sorry for that :(

2010/1/12 Sam Liddicott <sam liddicott com>

> * Jiří Zárevúcky wrote, On 12/01/10 14:43:
>
>  Sam Liddicott píše v Út 12. 01. 2010 v 07:25 +0000:
> > > Overloading could easily be supported with mandatory cname or csuffix
> > > attributes; that an explicit name needs to be given for C is no reason that
> > > it needs to be given for vala which could do regular overloading.
> > >
> > > I think it ought to be supported.
> > >
> > > Sam
> >
> > That's a matter of opinion. If Vala supported it, people would start
> > using cnames like "lib_class_some_action", "lib_class_some_action2",
> > "lib_class_some_action3", etc. Overloading exists because people are
> > lazy, ain't that true? :) Even if they wouldn't, it would still make
> > things considerably messier IMO (I, for one, do like the way I can use
> > most C libraries without separate Vala docs or searching VAPI).
> The point is that although the user needs to come up with alternative
> names, vala doesn't need to use them, and so the official reason for not
> supporting overloading is nonsense.
>
> You present a new reason, that users who are idiots, will chose idiotic
> names. Such users may do this anyway...
>
>  But anyway, if you really want it, you could just implement it and send
> > it to Jürg for approval.
> I've played that game before, and lost. There's no point in working on any
> feature if it is not in accordance with Jürg's vision for the language.
>
> >  Just think whether you really need it. From my
> > POV, it's pointless.
>
> I have my own reasons for distrusting it, how will overloading work with
> automatic type promotions, maybe at one instant the int value passed as an
> argument gets upgraded to a long int, but later someone overloads for int -
> your code now has a different code path without you expecting it, lets hope
> the new code path works like the old one. Of course the user should make it
> like that, but automatic type promotion and overloading worry me.
>
> But despite that, I find it useful. Who wants to keep repeating the type of
> an argument on the end of a function name? It's the last vestige of
> lpcszName type notation. Such information belongs in the computer and shown
> with nice markup.
>
>
>  BTW, please use a mail client that supports message threads. :)
> >
> Sorry - stinkin pocket outlook :-(
>
> Sam
>
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list