Fredderic Unpenstein píše v Pá 05. 02. 2010 v 17:14 +1100:
(Re-posted to the group, didn't mean to send it to Jiri personally...) I understand that. No one wants to do someone else's work for no forseeable gain. And it likely would be a fair bit of work, sorting out the resultant mess of what can and can't be conversed to fit which overloaded definition.
I wouldn't be concerned with that. Adding support for overloading doesn't mean we would immediately rewrite all the APIs to use it.
I do though, think this is a wonderful idea. There's a lot of cases of function, and then several function_with_something's, and I think there were even a few function_with_something_and_something's, where the difference is an extra argument or several on the end. Forcing the "with_something" to be exlicitly attaced at definition time, would help encourage some degree of thought, while shortening a whole bunch of horrifically long function names. While these are good for documentation, they're mostly redundant and sometimes force the programmer to do feats of syntactical gymnastics with their source code layout to accomodate the name (I've ended up resorting to dropping #define's into my C code to shorten some of them to a more practical length - not exactly reader-friendly either). Especially when it's got a few arguments of its own, or its return value is then used in a further immediate statement, and you want your own variables to have decently descriptive names. There's only so much room on a line!
As far as beauty of the code is concerned, it is useful. I agree with that. Yet it's still a very limited amount of cases. There is also the problem that some people are using overloads for functions that do entirely different things and just happen to have the same name for some reason. (I know that stupid programmer will find other places to mess things up, but still..) My opinion is that if this kind of overloading should be supported, then we would at least need some very strict guidelines about using it in bindings and libraries. And no constructor overloading! Named constructors are one of the things I totally love about the language.
And if someone wants to call their "function_with_something" as just "function2" in their own code, so be it. It'll be their problem if it then has to be interfaced with something else. I'm sure if they try to pull that off in a useful library, they'll get plenty of people throwing hate mail in their direction. But as pointed out, they already have the freedom to do just that in straight C. Heck, I've seen it done in C++ too, and THEN overloaded.
Well, then. Let's say name mangling is done explicitly by the programmer and we have guidelines. What about resolution rules? :) Don't forget about generics, pointers, GValues, GVariants, ownership modifiers and all that mess. You'll also need to properly check that all overloads can be automatically distinguished. That will be a lot of code and if you can do all this in a pretty way (so as not to make juergbi's eyes bleed when reviewing the patch), I will probably have no objection against inclusion. Good luck :)
Fredderic
Attachment:
signature.asc
Description: Toto je digitálně podepsaná část zprávy