Devin Mullins wrote:
> Trans wrote:
>
> >I think that you have the right sentiment, but the implemenation isn't
> >so good. It would make methods more compicated things to deal with. To
> >achieve signiture bases defintoins I think its best to stick with
> >multiple definitions:
> >
> >
> There are a couple of problems with the typical definition of multiple defs:
> 1. Matz has said that he won't implement them. :)
> 2. What method are you refering to when you call method, remove_method,
> etc.? In Ruby, the method signature is its name -- changing that would
> be a bigger deal.
> 3. It doesn't play well with inheritance. Suddenly you've got to think
> really hard when overriding a method (making sure to remove all
> implementations with different arity, or whatever).
> 4. It doesn't play well with optional args and splats. My way
> establishes an obvious order of resolution -- if the first one doesn't
> match, go onto the next one. The typical way doesn't, and is one of the
> confusing things about method overloading in C++ (by type in that case,
> but same diff).
>
> My way might squish ordef definitions together a little more (though
> you're free to use blank lines), but it maintains the idea of a method
> as an atomic unit -- the ordef thing is just an assistant to make
> dealing with different arities nice. It would make method definitions as
> complicated as you make them. If you really have one method doing three
> different things based on arity, then your central ordef thing should be
> nothing but a dispatcher to other methods.
>
> The one problem I see with it -- not reproducible by blocks and
> define_method. But, in that case, just do it the old fashioned way, as
> has already been covered on this thread.

You make some good points. But it occurs to me that having seperated
defs could in effect work in the same way as what you propose, with the
excpetion of controlling the order --but that I think should be airty
dictated anyway. How does the following, for instance, make any sense:

  def x(*a)
    ...
  ordef x(a)
    ...
  end

If it works like a case statement, the the last will never be reached.
Also if this is just a helper, you probaby could do it now with a case
statement, let me see...

  def x(*args)
    case args.size
    when 0
      ...
    when 1
      a = *args
      ...
    when 2
      a,b = *args
      ...
    else
      ...
    end
  end

Pretty simpe, if not quite as concise. Also I reacall a "real" solution
to this somewhere --writen by an old school Japanese Ruby Hacker. But I
can't seem to track it down. Anyone recall?

> The other is that, if it were adopted, the next thing asked for would be
> ordef's based on ===:
>
> def foo String => bar
> ordef foo Regexp => bar
> end
>
> def foo "add" => action, *args
> ordef foo "delete" => action, *args
> end
>
> And that would condone some pretty obvious smells. :)

You betchya :)

T.