Not grasping the method overloading/multi-dispatch thing

Hello –

(Starting a new thread, to make it easier to ignore :slight_smile:

I’ve been following the multi-method/dispatch thread, and finding
myself not grasping an important central part of it.

Namely… doesn’t this more or less completely change the nature of
Ruby?

At a fundamental level, I’m not getting how method signatures and
dispatching on type could be “added” to Ruby, such that Ruby was
still, so to speak, Ruby. Among other things, once that option
existed, I think we’d see a lot of code where there was only one
version of a method, but it was still typed.

OK, trying to clear the cobwebs and think it through…

It seems to me that exactly one of the following three things has to
be true:

  1. no OO language L can exist, such that (a) L is a good
    language, and (b) L does not have dispatching on type;
  2. there can be such a language (a good OO language which does not
    have dispatching on type), but Ruby is not such a language;
  3. there can be such a language, and Ruby is such a language.

I tend to lean toward #3 (with “good” understood as shorthand for
something like “not in need of fundamental, character-altering design
changes”).

Really and truly inviting explanation/enlightenment/clarification; I
just don’t get it.

David

···


David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

dblack@candle.superlink.net writes:

Hello –

(Starting a new thread, to make it easier to ignore :slight_smile:

I’ve been following the multi-method/dispatch thread, and finding
myself not grasping an important central part of it.

Namely… doesn’t this more or less completely change the nature of
Ruby?
Yes it does. Therefor it won’t happen.

At a fundamental level, I’m not getting how method signatures and
dispatching on type could be “added” to Ruby, such that Ruby was
still, so to speak, Ruby. Among other things, once that option
existed, I think we’d see a lot of code where there was only one
version of a method, but it was still typed.
As Matz pointed out overloading would be in the spirit of Ruby

OK, trying to clear the cobwebs and think it through…

It seems to me that exactly one of the following three things has to
be true:

  1. no OO language L can exist, such that (a) L is a good
    language, and (b) L does not have dispatching on type;
    I don’t think this states what it should. It’s not possible to think
    of an OO languages witout types read class.
  1. there can be such a language, and Ruby is such a language.
    No Ruby method do know qute well what types and methods belong to
    which class.

Regards
Friedrich

Dunno. That’s Matz’ call, of course. I can tell you how they work.
Figuring out whether they should work is another matter entirely.

···

At 8:05 PM +0900 9/12/02, dblack@candle.superlink.net wrote:

Hello –

(Starting a new thread, to make it easier to ignore :slight_smile:

I’ve been following the multi-method/dispatch thread, and finding
myself not grasping an important central part of it.

Namely… doesn’t this more or less completely change the nature of
Ruby?


Dan

--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk

(warning: long)

I’ve been following the multi-methods thread closely and having
recently completed the book “The Art of the Meta-Object Protocol” by
Kiczales et al. (matz Must have read this book, it’s so ruby-ish (and
ruby is so MOP-ish)), so I’ve got multi-methods on the brain.

My infatuation aside, I’ve been following everyone’s arguments and my
opinion is that multi-methods may not be needed in Ruby due to Ruby’s
special ability to redefine classes on the fly.

Some background:

I see overloading/multi-methods/paramater typing as useful in those
cases where we want to multiply, over a given operation, one set of
types by another.

For example, we might have some graphical objects and a Screen or a
Printer on which to draw them. So that would be multiplying over the
print operation:

{ Screen, Printer } print { Circle, Triangle, Square }

Or, perhaps the normal Xml printing problem over the toXmlString
operation:

{ XmlSerializer,
RdfSerializer } toXmlString { DataNode,
OpNode,
TypeNode }

Or, various execution contexts over execute on various command
types:

{ ImmediateExecutor,
QueuedExecutor,
SecureExectutor } execute { ReadOnlyCommand,
TransactionalCommand,
TaintedCommand }

So my question for myself and everyone else is: Where does this
multiplied -between- logic belong in Ruby?

In Other Languages, (Java, C++, CLOS), it belongs in the class itself
and the dispatch decision among the various overloaded methods is made
on the TYPE of the given arguments.

Java:

class XmlSerializer {
public void serialize( DataNode n ) { /* do stuff to DataNode / }
public void serialize( OpNode n ) { /
do stuff to OpNode / }
public void serialize( TypeNode n ) { /
do stuff to TypeNode */ }
}

In CLOS, quite differently, it belongs -between- the class
definitions, but the decision is still based on type. To me, this is
appropriate (just ask the AspectOriented folks) but this style still
requires typed parameter lists and multi-methods…

;;you don’t really need this per-se since all the logic is in the
;;serialize methods, but let’s pretend we’ve got a bunch of possible
;;serializer types
(defclass xml-serializer ()
())

(defgeneric serialize (stream node))

(defmethod serialize ((stream xml-serializer) (node data-node))
;;data node stuff)
(defmethod serialize ((stream xml-serializer) (node type-node))
;;type node stuff)
(defmethod serialize ((stream xml-serializer) (node op-node))
;;op node stuff)

So, in Ruby, where does this -between- stuff currently belong?

You could do the dispatch yourself inside one (or each) of the classes
on one side of the multiplication (ala Java):

class XmlSerializer
def serialize( node )
case node
when TypeNode:
serializeTypeNode( node )
when DataNode:
serializeDataNode( node )
end
end
end

Or you could put it inside one (or each) of the classes on one side,
and use an idiom that I think captures the -between-ness in a uniquely
Ruby way (akin to DoubleDispatch):

class XmlSerializer #this is the ‘owner’ of this -between- logic

#the key is to define specialized operations on all of the
#intended partner types

class << TypeNode
  def between-XmlSerializer-Nodes-serialize( serializer )
# do TypeNode stuff
  end
end

class << DataNode
  def between-XmlSerializer-Nodes-serialize( serializer )
# do DataNode stuff
  end
end

class << OpNode
  def between-XmlSerializer-Nodes-serialize( serializer )
# do OpNode stuff
  end
end

# and now, the main method
def serialize( node )
  node.between-XmlSerializer-Nodes-serialize( self )
end

end

This method has a few stengths:

  1. easy to understand

  2. you circumvent overloading/multi-methods (NOTE: you can define
    -between- methods as high-up in the target class heirarchy as you
    like, for example on the generic Node class)

  3. requires no changs to ruby

  4. captures the ‘cross-cutting’ nature of the AspectOriented ideas
    (modularizes the concern)

  5. namespaces the methods in the target classes to prevent collisions

Is this the extent of the usefullness of overloading/multi-methods or
do we need more?

Also, is this too weird? We are changing other classes’ definition’s
without their consent, but it does seem Ruby-ish to me…

-Rob

···


Thus far we seem to be worse off than before - for we can enormously
extend the record; yet even in its present bulk we can hardly consult
it. --Vannevar Bush, 1945

Hi –

dblack@candle.superlink.net writes:

At a fundamental level, I’m not getting how method signatures and
dispatching on type could be “added” to Ruby, such that Ruby was
still, so to speak, Ruby. Among other things, once that option
existed, I think we’d see a lot of code where there was only one
version of a method, but it was still typed.

As Matz pointed out overloading would be in the spirit of Ruby

Right, but that’s the part I don’t get :slight_smile: I’m picturing things like:

def meth(Integer n, String s)

def meth(Float f, String s)

and somewhere along the line I’m not clear on how that fits into the
spirit/design/philosophy of Ruby.

David

···

On Thu, 12 Sep 2002, Friedrich Dominicus wrote:


David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

My opinion: It just doesn’t.
To declare variables at all is not Rubyish IMO
(especially when assigning types, which can be
a separate issue).
To create a method signature by assigning types
to parameters is even worse, as far as I can see.
It looks like a huge step backward toward Java
and C++.

Hal

···

----- Original Message -----
From: dblack@candle.superlink.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, September 12, 2002 7:14 AM
Subject: Re: not grasping the method overloading/multi-dispatch thing

Hi –

On Thu, 12 Sep 2002, Friedrich Dominicus wrote:

dblack@candle.superlink.net writes:

At a fundamental level, I’m not getting how method signatures and
dispatching on type could be “added” to Ruby, such that Ruby was
still, so to speak, Ruby. Among other things, once that option
existed, I think we’d see a lot of code where there was only one
version of a method, but it was still typed.

As Matz pointed out overloading would be in the spirit of Ruby

Right, but that’s the part I don’t get :slight_smile: I’m picturing things like:

def meth(Integer n, String s)

def meth(Float f, String s)

and somewhere along the line I’m not clear on how that fits into the
spirit/design/philosophy of Ruby.

David, as I understand it, of course you would still be able to do

def meth(f, s)

which would be equivalent to

def meth(Object f, Object s)

Only if you wanted to have a different behaviour dependend on the
types of the arguments you would do something like

def meth(Integer n, s)
def meth(Float f, s)

So it really would be an addon to current Ruby, not breaking any
existing code.

HTH

Regards,
Pit

···

On 12 Sep 2002, at 21:14, dblack@candle.superlink.net wrote:

As Matz pointed out overloading would be in the spirit of Ruby

Right, but that’s the part I don’t get :slight_smile: I’m picturing things like:

def meth(Integer n, String s)

def meth(Float f, String s)

and somewhere along the line I’m not clear on how that fits into the
spirit/design/philosophy of Ruby.

A friend pointed out one major plus to static typing: documentation of
argument types. This feature seems to be envy of that plus.

dblack@candle.superlink.net wrote in message news:Pine.LNX.4.44.0209120814070.24122-100000@candle.superlink.net

Right, but that’s the part I don’t get :slight_smile: I’m picturing things like:

def meth(Integer n, String s)

def meth(Float f, String s)

and somewhere along the line I’m not clear on how that fits into the
spirit/design/philosophy of Ruby.

Dave, I’m inclined to agree with you. A major utility of Ruby is that
you can pass something that the original coder didn’t anticipate, as
long as it responds to the appropriate messages. Given the example
above, a guarding .to_f or .to_i within :meth does the job while being
more flexible.

The guarding conversion would let one pass in a string from a CGI
param, for example.

So…

I think the benefit people are looking for is the documentation
benefit – this method expects a string, etc. There are easier ways
of solving documetation problems, like making rdoc a standard library
:slight_smile:

~ Patrick

Hi,

As Matz pointed out overloading would be in the spirit of Ruby

Right, but that’s the part I don’t get :slight_smile:

That’s not what I meant. I meant that I don’t see any problem of
multi-method in overloading method. That’s all.

I’ve preferred the idea of overloading method since before I designed
Ruby. But Ruby still doesn’t have one. That indicates something.

Guy, who did implement it in his “modified Ruby”, might want to tell
you how he felt.

						matz.
···

In message “Re: not grasping the method overloading/multi-dispatch thing” on 02/09/12, dblack@candle.superlink.net dblack@candle.superlink.net writes:

As long as not declaring an argument type would mean “Object” (or any
type) you wouldn’t loose anything. Currently you can use self-made
overlaoding methods like that (untested):

class Foo

def self.overload(symbol, args, proc)
	@@methods << [:symbol, args, proc]
end

def call_overload(symb, *args) 
	types  = args.map{|a| a.type}
	method = @@methods.find { |a|
		a[0] == symb && a[1] == types
	}
	raise ArgumentError,
	      "Unable to find overloaded method for #{symb}, #{types.inspect}"
	  unless method

	method.call(*args)
end

overload :meth, [Integer, Integer], Prow.new { |a,b| a.to_s + b.to_s } 
overload :meth, [Object, Object],    Prow.new { |a,b| a + b } 

def meth(arg1, arg2)
	do_overload(:meth, arg1,arg2)
end

end

Foo.new.meth(“s”, “b”) # => sb
Foo.new.meth(“s”, 1) # => s1
Foo.new.meth(2, 1) # => 21

The same could be implemented with the folling hypothetical syntax:

class Foo
def meth(Integer i, Integer j)
i.to_s + j.to_s
end

def meth(Object o1, Object o2) 
	o1+o2
end

end

Which is reasonably shorted and easier to understand. I see a need for
this as I find myself often manually dispatching to methods by the type
of an argument.

-billy.

···

On Thu, Sep 12, 2002 at 09:53:31PM +0900, Hal E. Fulton wrote:

From: dblack@candle.superlink.net
Sent: Thursday, September 12, 2002 7:14 AM

On Thu, 12 Sep 2002, Friedrich Dominicus wrote:

dblack@candle.superlink.net writes:

As Matz pointed out overloading would be in the spirit of Ruby

Right, but that’s the part I don’t get :slight_smile: I’m picturing things like:

def meth(Integer n, String s)

def meth(Float f, String s)

and somewhere along the line I’m not clear on how that fits into the
spirit/design/philosophy of Ruby.

My opinion: It just doesn’t.
To declare variables at all is not Rubyish IMO
(especially when assigning types, which can be
a separate issue).
To create a method signature by assigning types
to parameters is even worse, as far as I can see.
It looks like a huge step backward toward Java
and C++.


Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0
eLösungen 89077 Ulm Fax: +49-731-399 499-9

I guess you COULD do this:

def meth(n, s)

where is a hint to the runtime to use if present (and not
demanding its presence in most cases). The ‘s’ does not have a hint of
type, so is excluded from enabling MM stuff.

-rich

···

-----Original Message-----
From: Hal E. Fulton [mailto:hal9000@hypermetrics.com]
Sent: Thursday, September 12, 2002 8:54 AM
To: ruby-talk ML
Subject: Re: not grasping the method overloading/multi-dispatch thing

----- Original Message -----
From: dblack@candle.superlink.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, September 12, 2002 7:14 AM
Subject: Re: not grasping the method overloading/multi-dispatch thing

Hi –

On Thu, 12 Sep 2002, Friedrich Dominicus wrote:

dblack@candle.superlink.net writes:

At a fundamental level, I’m not getting how method
signatures and

dispatching on type could be “added” to Ruby, such that
Ruby was

still, so to speak, Ruby. Among other things, once that option
existed, I think we’d see a lot of code where there was
only one

version of a method, but it was still typed.

As Matz pointed out overloading would be in the spirit of Ruby

Right, but that’s the part I don’t get :slight_smile: I’m picturing
things like:

def meth(Integer n, String s)

def meth(Float f, String s)

and somewhere along the line I’m not clear on how that fits
into the
spirit/design/philosophy of Ruby.

My opinion: It just doesn’t.
To declare variables at all is not Rubyish IMO
(especially when assigning types, which can be
a separate issue).
To create a method signature by assigning types
to parameters is even worse, as far as I can see.
It looks like a huge step backward toward Java
and C++.

Hal

Hi –

As Matz pointed out overloading would be in the spirit of Ruby

Right, but that’s the part I don’t get :slight_smile: I’m picturing things like:

def meth(Integer n, String s)

def meth(Float f, String s)

and somewhere along the line I’m not clear on how that fits into the
spirit/design/philosophy of Ruby.

David, as I understand it, of course you would still be able to do

def meth(f, s)

which would be equivalent to

def meth(Object f, Object s)

Only if you wanted to have a different behaviour dependend on the
types of the arguments you would do something like

def meth(Integer n, s)
def meth(Float f, s)

So it really would be an addon to current Ruby, not breaking any
existing code.

True, it wouldn’t break code, but it would (for me) completely change
the “feel” of Ruby. Also, I think we’d start to see very little of
this:

def meth(n)

and lots and lots of this, even where it wasn’t necessary:

def meth(Integer n)

I think the availability of this kind of thing would deter many people
from exploring what is unique about Ruby.

David

···

On Thu, 12 Sep 2002, Pit Capitain wrote:

On 12 Sep 2002, at 21:14, dblack@candle.superlink.net wrote:


David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

In article 3D80AD8D.27388.FBF0F18@localhost,

As Matz pointed out overloading would be in the spirit of Ruby

Right, but that’s the part I don’t get :slight_smile: I’m picturing things like:

def meth(Integer n, String s)

def meth(Float f, String s)

and somewhere along the line I’m not clear on how that fits into the
spirit/design/philosophy of Ruby.

David, as I understand it, of course you would still be able to do

def meth(f, s)

which would be equivalent to

def meth(Object f, Object s)

Only if you wanted to have a different behaviour dependend on the
types of the arguments you would do something like

def meth(Integer n, s)
def meth(Float f, s)

So it really would be an addon to current Ruby, not breaking any
existing code.

I’m kind of torn between the two sides on this one…

Currently if we need a method that does two different things based on
the type of an argument we have to do:

def meth(s)
case s
when Integer
#do something
when Float
#do something else
end
end

It would be nice to be able to declare two meth methods as shown above
instead of having to test the type of the argument.

However, I also agree with David that this could change the nature of the
language. I also suspect that there will be a performance
hit for all code even if you don’t use method overloading. IF it could be
implemented in such as way as to not impact performance if you don’t use
the feature, then I’d probably lean towards doing it.

Phil

···

Pit Capitain pit@capitain.de wrote:

On 12 Sep 2002, at 21:14, dblack@candle.superlink.net wrote:

Guy, who did implement it in his "modified Ruby", might want to tell
you how he felt.

  Well, I can't say more than what I've said in [ruby-talk:26914] (sorry I
  can't give a better explanation, becuase of my bad english, why I think
  that it's not a good idea to add overloading in ruby).

More, one day I've just written this :

pigeon% cat b.rb
#!./ruby
class AA < Array
end

class A
   private
   def tt(Enumerable a)
      yield "Enumerable"
   end

   public
   def tt(Array a)
      yield "Array"
      next_method
   end
   def tt(AA a)
      yield "AA"
      next_method
   end
   def tt(String a)
      yield "String"
      next_method
   end

end

p A.instance_methods
p A.private_instance_methods
a = A.new
a.tt(AA.new 1, 2) {|i| puts "received #{i}" }
a.tt("string") {|i| puts "received #{i}" }
a.tt(1 .. 2)

pigeon%

pigeon% b.rb
["tt"]
["next_method", "tt"]
received AA
received Array
received Enumerable
received String
received Enumerable
./b.rb:32: private method `tt' called for #<A:0x401afb68> (NameError)
pigeon%

See the module (rather than the class) in the definition.

This was my way to *kill* it because I know that when I've written it this
will give, one day, some incoherence.

Guy Decoux

Hello –

As long as not declaring an argument type would mean “Object” (or any
type) you wouldn’t loose anything.

Except the existence of a programming language that makes you think
about things in a different way :slight_smile:

[…]

class Foo
def meth(Integer i, Integer j)
i.to_s + j.to_s
end

def meth(Object o1, Object o2)
o1+o2
end
end

Which is reasonably shorted and easier to understand. I see a need for
this as I find myself often manually dispatching to methods by the type
of an argument.

This I think is the heart of the matter. I guess it depends who you
ask… but there’s certainly a school of thought to the effect that
dependence on type in Ruby programming is, in some sense,
un-Ruby-like, because in fact objects are dynamic and can change. At
any given time, an object does what it does; its type is not a
guarantor of its behavior. Even its (virtual) class acquiesces in
this. To write a Ruby program is to create opportunities for
meaningful conjunctions of dynamic behaviors.

Here’s my view of this:

It’s true.

It’s so profound that I haven’t begun to fathom it.

The real question about Ruby, if there is one, is how much there is
to fathom, and exactly what this dynamism, together with what
surrounds it (including auxiliary practices like unit testing), has
the potential to amount to.

Adding “def meth(Integer n)” to Ruby will stop people from even
bothering to try to fathom it.

That’s essentially what I mean when I say that the discussion of
method overloading concerns me at the level of the “feel” of Ruby.

David

···

On Thu, 12 Sep 2002, Philipp Meier wrote:


David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

This isn’t necessary; see Hal’s example of another alternative (declare
a method in the Integer and Float classes that gets called from meth(),
so that meth() follows the same code path for whatever type you use).
The downside is that you have to modify those classes in order for this
to work.

Paul

···

On Fri, Sep 13, 2002 at 03:40:42AM +0900, Phil Tomson wrote:

Currently if we need a method that does two different things based on
the type of an argument we have to do:

def meth(s)
case s
when Integer
#do something
when Float
#do something else
end
end

It would be nice to be able to declare two meth methods as shown above
instead of having to test the type of the argument.

yes it would be nice.

However, I also agree with David that this could change the nature of the
language. I also suspect that there will be a performance
hit for all code even if you don’t use method overloading. IF it could be
implemented in such as way as to not impact performance if you don’t use
the feature, then I’d probably lean towards doing it.

a loss of 50% performance is compensated for in 18 months by moore’s
law. in this case i imagine we’re talking around 1%.

sounds like a nice feature, it has been mentioned before but now has a
much better conceptual model to stand on.

i think it stands a chance of making ruby more “ruby”, rather than less.
though i understand the trepidation.

···

On Thu, 2002-09-12 at 12:40, Phil Tomson wrote:


tom sawyer, aka transami
transami@transami.net

Hi –

I’m kind of torn between the two sides on this one…

Currently if we need a method that does two different things based on
the type of an argument we have to do:

def meth(s)
case s
when Integer
#do something
when Float
#do something else
end
end

It would be nice to be able to declare two meth methods as shown above
instead of having to test the type of the argument.

I guess what I’m wondering is why the idea of Ruby as a language which
does things in ways other than testing-for-type seems to be falling
out of favor. Just when it was getting exciting, at least for me…

However, I also agree with David that this could change the nature of the
language. I also suspect that there will be a performance
hit for all code even if you don’t use method overloading. IF it could be
implemented in such as way as to not impact performance if you don’t use
the feature, then I’d probably lean towards doing it.

Once it’s possible to sign methods by type, I seriously doubt that
very many newcomers to Ruby (at the very least) would write very many
methods where they didn’t. Hard to predict… but I still root for
the alternative.

David

···

On Fri, 13 Sep 2002, Phil Tomson wrote:


David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

> Currently if we need a method that does two different things based on > the type of an argument we have to do: > > def meth(s) > case s > when Integer > #do something > when Float > #do something else > end > end > > It _would_ be nice to be able to declare two meth methods as shown above > instead of having to test the type of the argument.

My 2 cents: When I find that I am testing type, as above, then it usually
means that it’s time to refactor. Then you can have two methods with the
same name, but in different classes, where they belong.

···

On Thursday 12 September 2002 01:40 pm, Phil Tomson wrote:

However, I also agree with David that this could change the nature of the
language. I also suspect that there will be a performance
hit for all code even if you don’t use method overloading. IF it could be
implemented in such as way as to not impact performance if you don’t use
the feature, then I’d probably lean towards doing it.

Phil

In Phil’s example, it seems like “meth” is testing the argument’s
class, not its type. According to my copy of Design Patterns, the
type of an object is the set of methods to which it can respond. If
two objects respond to the same set of methods then they have the same
type, even if they aren’t objects of the same class.

For me, testing an argument’s class is a code smell. What do I care if
"s" is a Foo or a Bar, as long as it responds to the methods I need to
send it? I try to design my classes and methods so that, if I want
method “A” to accept as arguments objects that are created from
different classes, then each of the classes should implement the set
of methods that “A” will send. As far as “A” is concerned, all the
objects have the same type.

So, for the case where you want to “overload” concat to accept EITHER
String objects or Fixnum objects:

concat("A", "B") -> "AB"
concat("A", 1) -> "A1"
concat(1, 2) -> "12"

then you define concat as

def concat(arg1, arg2)
arg1.to_s + arg2.to_s
end

Since both String and Fixnum objects respond to to_s, they’re both the
same type as far as concat is concerned.

(snip)

···

On 12 Sep 2002 17:57:41 GMT, ptkwt@shell1.aracnet.com (Phil Tomson) wrote:

I’m kind of torn between the two sides on this one…

Currently if we need a method that does two different things based on
the type of an argument we have to do:

def meth(s)
case s
when Integer
#do something
when Float
#do something else
end
end

It would be nice to be able to declare two meth methods as shown above
instead of having to test the type of the argument.

However, I also agree with David that this could change the nature of the
language. I also suspect that there will be a performance
hit for all code even if you don’t use method overloading. IF it could be
implemented in such as way as to not impact performance if you don’t use
the feature, then I’d probably lean towards doing it.

Phil