From: dblack@...
Date: 2002-09-12T22:44:45+09:00
Subject: Re: not grasping the method overloading/multi-dispatch thing

Hello --

On Thu, 12 Sep 2002, Philipp Meier wrote:

> 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 :-)

[...]

> 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

-- 
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