Re: [Vala] Support for method overloading.

Sam Liddicott píše v Út 12. 01. 2010 v 16:04 +0000:
* 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 

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.

I think the official reason is actually "nobody has shown us it is worth
the trouble". I second that.

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

Well.. I didn't succeed with string templates as well and they made
their way into Vala later on, even without my effort.
Opinions change, so I see the possibility of overloading being supported
in some distant future, whatever the form. Not that I need or support

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.

See? All the trouble and so little to gain.

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.

Fields with different type and function have different names. I don't
see anything wrong with that.

Try imaging overloaded variables. That would be SO wrong.  

BTW, please use a mail client that supports message threads. :)
Sorry - stinkin pocket outlook :-(

Ewww. Don't use that. You will die a horrible death.


Attachment: signature.asc
Description: Toto je digitálně podepsaná část zprávy

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