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 <[email protected]>
> * 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
> [email protected]
> http://mail.gnome.org/mailman/listinfo/vala-list
>
>
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
