[#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 19:59:56 UTC
List: ruby-core #1476
On Mon, 25 Aug 2003, Sean E. Russell wrote:

> When I think of Ruby mixins, I think of adding methods to an object
> (or class)  - -- a function-oriented procedure.  In Ruby, commonly,
> these mixins aren't object oriented -- that is, they don't generally
> operate on the object they're attached to.  They don't affect the
> state of an object, and they don't make any assumptions about the
> object context.(1).
> (1) Ruby mixins *can* modify the state of an object, but most of the core Ruby 
> modules don't.   Therefore, I speak not of what Ruby "can do", but what Ruby 
> "does", in a "best practices" sort of way.

I don't call this "best practices", I call it "basic practices". The core
Ruby, if you mean what's inside the interpreter, is not very much using
modules. If you look at Ruby's standard library, you'd find a much bigger
sample of what apparently accepted practice is according to maintainers of
Ruby.

Then you'd find out that they often have their own instance variables.

Besides, operating on an object isn't necessarily having to do with
reading or writing instance variables. There are many methods that are
defined solely in terms of other methods. I don't know how that makes
things less "object oriented", and where you learned to think that.

> Inheritance is, in my mind, a different beast altogether.  OO inheritance 
> implies state and context.  Inherited methods are *expected* to modify the 
> state of the object, or report on the state of the object based on some 
> intimate knowledge of the object. If they don't, good OO design suggests 
> that they probably shouldn't be object methods in the first place.

OK, could you please give me a reference on that "good OO design" thing
you are talking about. After a decade of OOP I still can't figure out
"good OO design" myself it seems.

Also, your "good OO design" seems to be utterly ignored by implementors of
such software as GNU Smalltalk, and I don't know how many other
environments, as they define lots of methods solely by using other
methods. So your "good OO design" makes me doubly curious.

> I'd say a more useful way of looking at Ruby 
> mixins is "can".   Mixins are verbs; inheritance is nouns.

oh yeah, an Array "can" Enumerable. I've been told that class names are
akin to nouns, like [], [1,2,3] are Arrays, mixin names are akin to
adjectives, like Arrays are Enumerable, and that methods are verb-like.
What do you think of that?

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


In This Thread