[#1378] differences between Module and Class ? — Mathieu Bouchard <matju@...>

25 messages 2003/08/11
[#1387] Re: differences between Module and Class ? — matz@... (Yukihiro Matsumoto) 2003/08/12

Hi,

[#1442] Re: differences between Module and Class ? — Mathieu Bouchard <matju@...> 2003/08/21

[#1406] _id2ref bug? — Ryan Pavlik <rpav@...>

While debugging some caching code, I've come across a segfault related

22 messages 2003/08/14
[#1407] Re: _id2ref bug? — matz@... (Yukihiro Matsumoto) 2003/08/14

Hi,

[#1413] Re: _id2ref bug? (REPRODUCED, short) — Ryan Pavlik <rpav@...> 2003/08/14

On Fri, 15 Aug 2003 01:57:18 +0900

Re: differences between Module and Class ?

From: Mathieu Bouchard <matju@...>
Date: 2003-08-24 23:37:59 UTC
List: ruby-core #1478
On Mon, 25 Aug 2003, Sean E. Russell wrote:

> An Array "can" Enumerate, and that's what allows it to expose methods in the 
> "Enumerable" namespace.

I see that you have not replied to the part on "good OO design". I would
have liked a book reference. If you cannot find such a thing, I will
assume that it doesn't exist and that you made up those rules.

> IME, mixins tend to be more for the benefit of the the object user,
> than for the object itself; whereas with inheritance, the
> functionality is of more use to the object that extends the
> superclass.

Do you ever create objects and classes for their own benefit, or aren't
they all created to actually be used ?

If you instead are talking about this "convenience mixin" concept I have
in MetaRuby: I ripped almost all out of Array/Hash/String and
reimplemented most methods into mixins, with only a handful of essentials
left in the classes; if you want to say that mixins are about convenience
methods, and that classes are about essentials, then I can assure you that
90% of Array/Hash/String is mere convenience, and can be (and have
been...) re-expressed in what you call "mixins", "not object-oriented",
and not "good OO design".

But not all mixins have a "bunch of convenient methods" nature, and nor do
they have to be (unless that's also covered by the rules of your "good OO
design"), and the original concept of mixin, as imagined in the 80's,
wasn't designed with such a limited purpose in mind.

You may consult my implementation of #undo/#redo on Array/Hash/String to
see that mixins are also about overriding methods in classes they don't
refer to!

> How about this perspective: mixins extend the behavior of
> an object, whereas in inheritance, the object extends the behavior of
> some superclass.

I don't understand this. You seem to be conflating the class and object
concepts... I mean in this sentence in particular.

Btw, I don't know why mixins shouldn't be called inheritance, because the
mixed-in modules still show up in the result of Module#ancestors, and if
the name "ancestors" has not been chosen because of inheritance, then I
don't see any other possibility.

> Again, this subthread isn't a technical discussion; I freely admit
> that everything *I'm* talking about is purely subjective.

You seem to think that "technical" and "subjective" are somehow opposed in
nature.

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


In This Thread