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 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. >
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 > language. 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 it. > > 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. > Sam
signature.asc
Description: Toto je digitálně podepsaná část zprávy
_______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
