ruby-core

On Fri, 22 Aug 2003, Yukihiro Matsumoto wrote:

>     on 03/08/21, Mathieu Bouchard <matju@sympatico.ca> writes:
> |2a. Class.new is moved to Object#new. A Class that does not have Object in
> |    its ancestor list does not inherit from Object#new and is thus
> |    uninstantiable.
> (2a) breaks inheritance tree.  It's not acceptable.

Woops, I wanted to write:

	Class#new is moved to Object.new

Which then makes sense, but supposing you understood me anyway, then I
don't understand how it breaks things. Is anyone relying on new() being
Class#new instead of Object.new ? It's just about bringing Class#new one
level down the hierarchy, at a point where it does not seem to matter
much: new() is supposed to create an Object, and so nothing more general
than Object.new is going to be called, and in the current situation the
method-lookup recurses from the class<<Object;self;end class to the Class
class, whereas in my proposal it does not. And because all instances of
Class are not directly of Class class, but instead are instances of
metaclasses inheriting from the Class class, no-one can make the
difference between Object.new and Class#new without using reflection. Is
this correct?

> In summary, your point is the following, right?
> |2. Pickaxe says "multiple inheritance [can be] dangerous, as the
> |inheritance hierarchy can become ambiguous. [Mixins] provide a controlled
> |multiple-inheritance-like capability with none of the drawbacks" (p.23).
> |Pickaxe was the first printed English book on Ruby, which for me was an
> |appropriate successor to ruby-man-1.4, and quite elegantly written.
> |However the part I've cited above is, after close examination, a wild,
> |bold opinion that I find very difficult to agree with.

> I know mix-in is restricted MI as you state.  So the question is why
> restrict where MI _can_ do it.
> * at the point of I designed Ruby, the concept of "mix-in" was not
>   known widely.  So I wanted to advocate "mix-in" by prohibiting
>   multiple inheritance, and making it a language feature.

Well it would be important to differentiate the different contexts those
words fit in. I am not being precise enough. Words change meaning from
community to community.

Ruby's Class/Module(/mixin) system is based on a method lookup which is
listing inherited functionality in a priority order, calling the first,
and then the "super" reserved word allows access to the next one.

LISP/CLOS's class system is based on a method lookup which is listing
inherited functionality in a priority order, calling the first found
method, and then the call-next-method macro allows access to the next one.

In LISP/CLOS, the term Mixin is sometimes used to designate a class that
calls call-next-method on methods it does not inherit, so that when it's
inherited from, it can override a previously unspecified class. This is
exactly the functionality that you can do in LISP/CLOS but not in C++ or
Ada or Perl (before 5.8). Apparently, the word Mixin also comes from LISP.

However the LISP folks usually call their inheritance scheme "Multiple
Inheritance". The phrase "Mixin Inheritance" is not very much used.

In literature it may happen that Mixin Inheritance is mentioned in
opposition to Multiple Inheritance. In that case, the latter really means
Non-Mixin Multiple Inheritance.

In that light, Ruby's inheritance is a restricted form of LISP's
multiple inheritance. What I want is that Ruby gets the unrestricted form
of LISP's multiple inheritance, and not any other kind of multiple
inheritance.

>  * you can (or forced to) distinguish is-a relation to has-a relation
>    with "single inheritance w/ mix-in".  I believe this distinction is
>    a good thing, which make relations clear.

I don't know what it is to be bilingual Japanese/English, but I am
bilingual French/English, and those are two rather related languages, and
yet I could pull several examples where it is very much unclear what
"is" and "has" deeply mean.

Let's use a simple example. "I am hungry" could be translated into French
as "Je suis affame", but in French no-one says that, and instead Frenchmen
say "J'ai faim", which could be translated directly into English as "I
have hunger", but then no-one says that either.

If it is questioned whether this is a good example of how the perception
of "having/being" is relative between languages, I can pull out many other
examples if spending enough time finding them.

Here my point is that even though IS-A and HAS-A of software design are
expressed as a parallel with everyday life, they are still software
concepts that can more precisely be described by HAS-A-POINTER-TO,
HAS-A-SUBPART, IS-A-SUBCLASS-OF, CAN-DO-THIS, etc. And in such a case,
given the common meaning of "subclassing", i don't see how #including a
Module can be anything else than IS-A-SUBCLASS-OF, and i don't see how
further hairsplitting is improving anything.

All of this as a prelude to asking you:

What are your precise definitions of IS-A and HAS-A ?

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju

Thread

Prev Next

In This Thread

Prev Next