Re: [Vala] Support for method overloading.


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.


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 :-(


Vala-list mailing list
Vala-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]