From: "Mauricio Fernández" <batsman.geo@...>
Date: 2002-09-27T22:11:49+09:00
Subject: Re: adding overload to ruby

On Fri, Sep 27, 2002 at 06:43:09PM +0900, Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: adding overload to ruby"
>     on 02/09/27, "Bulat Ziganshin" <bulatz@integ.ru> writes:
> 
> |YM>   * multiple method (as in CLOS, Dylan) does not fit in Ruby at all.
> |
> |can you please give me an example? i know many languages but
> |clos/dylan not in this list
> 
> (defmethod (plus (integer x) (integer y))
>    ....)
> 
> (defmethod (plus (float x) (integer y)
>    ....)
> 
> (plus a b)   ; invokes plus method depends on classes of a AND b
> 
> In multiple method, there's no one specific receiver.  Every argument
> is a part of receivers.

If this example is to be any different from overloading, the dispatch
must depend on the dynamic types of a and b (not on the static type, if
any).

Is the only difference between multiple method and overloading on
dynamic types the lack of a specific receiver?

I believe the issue underneath this discussion is the true nature of
types in Ruby. I'll try to expose my view on this:
 1) there's no static typing in Ruby, and *nobody* wants it. We'll never
 see C++-like overloading in Ruby.
 2) however Ruby is not type-less. Objects do have a (dynamic) type, but...
 3) the class doesn't describe the type of an object either, for there are 
 	singleton methods and mix-ins. I'll note this type "ClassType".
 4) that's why it seems there's a consensus around the following idea:
 	"the type is the set of messages an object responds to"
    I'll call this kind of type "MessType"
 5) we cannot use ClassType in method dispatch because we want to 
 	go on using generic methods. And the whole MessType is unusable
	too because the only way to specify it is... referring to an
	object and saying the MessType we're talking about is its!
 6) Java interfaces come to mind, but having to explicitly say that a
 	class implements Xxx, Yyy, Zzz, Fooo and Baaaar is quite
	inconvenient, and
 7) most of the times we are really interested on a couple methods being
 	supported by the passed object. If we want to discriminate based
	on individual methods being supported, we end up having one
	interface per method! Interfaces become senseless.

Therefore IMHO overloading can only depend on the presence of
individual methods, not on "types" whichever definition you take.
Unless, of course, you consider each method corresponds to an interface
and you state the interface _is_ the type, and each object can have lots
of types at the same time.

I think everything becomes fuzzy after point 5), for the name of a
method doesn't guarantee anything if there's no formal definition of the
semantics, but then again that is the body itself...

> |YM>   * but still, it's a big change to the language, so that we better be
> |YM>     conservative.
> |
> |we prefer to make small changes in language which give large impact on
> |easy of programming. and because this discussion arrived. but i personally
> |don't see at this moment something better than my first shoot
> |(syntactic sugar about overload.rb and using '===')
> 
> A small change can destory the total balance.  I didn't say "no".
> Just "wait".

Is this certain to be added in a way or the other? 
Is it planned for Rite? Is it possible that Ruby won't ever have these
features? 

[not that I want to push them, or the opposite, in fact I don't care much]

> |YM>   * besides, dispatch-on-type often is code smell (sign of bad code).
> |YM>     I'm still not sure whether it is good to encourage this practice
> |YM>     by supporting it by the language.
> |
> |it's intensively used already. as i stated above, first examined class - Array -
> |has 10% of functions overloaded. coerce is another bad side of current
> |ruby implementation
> 
>  (a) 10% usage does not mean it is good enough to encourage.  It is
>      mostly because of performance compromise.

Overloading, as I see it, is just a matter of 
 1) convenience
 2) performance if it's incorporated into the C core
for it can be done with Ruby as it is right now.

Of course this argument could apply for each and every feature of the
language, but I *feel* it is pertinent here. Perhaps because I feel 
the kind of overloading I'm thinking of wouldn't change Ruby much.

-- 
 _           _                             
| |__   __ _| |_ ___ _ __ ___   __ _ _ __  
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ 
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
	Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
  
Linux ext2fs has been stable for a long time, now it's time to break it
	-- Linuxkongre� '95 in Berlin