On 11/12/05, gabriele renzi <surrender_it / -remove-yahoo.it> wrote:
> Austin Ziegler ha scritto:
>> On 11/12/05, gabriele renzi <surrender_it / -remove-yahoo.it> wrote:
>>>Oh, the nicety of
>>>  def Math.sqrt(Positive p)
>>>:)
>> Hm. No. That would end up requiring a significant change to Ruby,
>> because sqrt is legal on negative numbers, as long as you have
>> imaginary (complex) number support available.
> yeah, I'm not really suggesting changing Math.sqrt, just an example.

Yeah, but it's a perfect example of what's wrong with trying to put
class restrictions as signatures in Ruby methods.

>> So you would then have to have overloading instead of simple
>> overriding as Ruby currently does, because you'd need def
>> Math.sqrt(Positive p) and def Math.sqrt(Negative p).
>>
>> Overloading, I have come to believe, is a nightmare compared to
>> duck-typing. That's one of the reasons I oppose *anything* that
>> threatens to put it into Ruby, because it's a mess.
> I was thinking of multimethods, more than simple overloading C++
> style, but I'm not sure if that belongs to ruby so I won't argue on
> this.

> But would you please explain why do you think multiple dispatch is a
> bad thing, it would be interesting to hear the reasons that brought
> you to this conclusion.

Part of it is the mess that is C/C++; part of it is the mess that is
Java. If I were able to say something like:

  class Foo acts as java.util.String
  {
	// ...
  }

  class Bar
  {
	public String baz(String x) { ... };
  }

it might be okay. I'm not necessarily after an inheritance relationship,
but even that's difficult. I am really finding that I prefer writing
code that I want to say "I need this behaviour" not "I need this class."
It's much harder to express that in a multimethod sort of thing, which
is predicated primarily on a preconceived notion that the only way to
get polymorphism is to specify multiple methods that deal with classes.

-austin
--
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca