Re: [Vala] Support for method overloading.

[Fredderic Unpenstein <magentus gmail com>]

(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