(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 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! 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. Fredderic _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
