On Mon, Jan 31, 2011 at 1:27 PM, Thomas E Enebo <tom.enebo / gmail.com> wrote:
> On Mon, Jan 31, 2011 at 9:00 AM, Gary Wright <gwtmp01 / mac.com> wrote:
>> I think the original poster provided an example of overloading based on the number of parameters but not their type.
>> Even restricting yourself to overloading by arity is a bit problematic in Ruby because the arity still has to be determined (in some cases) dynamically:
> Actually, arity of callsite is always calculated in Ruby to know if
> you should throw an ArgumentError (3 for 0 specified sort of errors)
> against the method you are calling. It seems like overloading based
> on arity is not such a bad idea to me based on some of the common
> arity parsing idioms people do by hand in the first few lines of their
> methods. What implementing arity-based overloads would do is get rid
> of most of this code we put at the top of methods and perform that
> logic in the Ruby implementation itself (in MRI in C vs in Ruby).

I'd also add that in JRuby, if the source arity matches the target
(non-rest, non-optional) arity, we do no calculation at all (for
arities up to 3). So if Ruby supported multiple overloads, it would
basically just work like our core arity-split methods do right now and
automatically route to the correct body.

> Stylistically, I think the biggest issue is not realizing there are n
> overloads and then implementing less than n overloads in an overridden
> class.

An *excellent* point. This bites overload-supporting static languages
very frequently too.

- Charlie