Hi --

On Mon, 7 Jun 2004, David Garamond wrote:

> David A. Black wrote:
> > The behavior of Ruby objects (what messages they respond to, and how
> > they respond) is bootstrapped *but not constrained* by their class.
> > It is possible to put this fact in the category of "enough rope to
> > shoot yourself in the foot" or whatever, and decide it's too powerful
> > to take advantage of or take into account when designing a program.
> > Personally, I see no reason to look at it that way; I like the idea of
> > programming with, not in spite of, Ruby's design.  But in any case,
> > whatever interpretation one puts on it, the behavior of Ruby objects
> > is not constrained by their class.
> > 
> > OK, now that means that there is Something Other Than Its Class that
> > characterizes and denotes the behavior of an object *more accurately*
> > than the name of its class (or of any mixins) does.  I'm not
> > extrapolating any philosophy of programming from this; I'm just
> > pointing it out.
> 
> What other things characterizes an object behaviour other than its 
> class? I know that Ruby allows us to change object e.g. with 
> Object#extend or adding singleton methods, but aren't those implemented 
> by creating an internal class?

Yes, but that class doesn't show up in things like #kind_of?, #class,
and even #instance_of?  By "its class", I really mean the class of
origin.  In fact, I favor the term "birth class" for this, to make a
pair with "singleton class" and to emphasize the point that an
object's instantiation from a class is only the beginning of its
journey through object-space.  So what I really would say (if I ever
succeed in making that terminology popular :-) is: Something Other
Than Its Birth Class.

So yes, the parting of the ways between class and type is, in fact,
implemented through the creation of a class.  Maybe one could say that
type == birth class + singleton class (i.e., the sum of their
capabilities).


David

-- 
David A. Black
dblack / wobblini.net