From: Sean O'Dell <sean@...>
Date: 2004-06-07T01:36:23+09:00
Subject: Re: How to ducktype a Hash?

On Sunday 06 June 2004 07:21, David A. Black wrote:
>
> We need a way to refer to this thing.  However, terms like "Something
> Other Than Its Class" or "An Object's Behavior At A Given Point" are
> obviously quite unwieldy.
>
> A much more concise term is "type".  It makes sense, too: "type", as I
> understand it across languages, is expected to tell you what an object
> can do, and that's just what we're looking for.  The fact that Matz
> has allowed an object's type to peel away from its class and chart its
> own course does not mean that the object does not have a type, in this
> sense of the term; and there is no reason not to simply refer to it
> that way.
>
> On the other hand, if we decide that type == class, then we're back
> where we started: we need a new term that refers to the
> Other-Than-Class thing.  We can't just not refer to it; it's at the
> heart of Ruby's design.  Moreover, if we rule out "type" and use it as
> a synonym for "class", it's going to create confusion, because two
> objects of the same class simply do not have to exhibit the same
> behaviors and when they don't, referring to them as having the same
> "type", on the basis of how they respond to the #class method,
> threatens to tie us in knots.

This is brilliantly put.  This is what I mean to say.  I like that classes can 
peel off and do their own thing.  But that means that the class has changed 
types, which is fine; I don't want to constrain classes, I just want to be 
able to IDENTIFY their type.  Types aren't something you can describe in 
Ruby, so except for perhaps in a very ethereal, conceptual sense, Ruby 
classes have no type.  There's nothing in the language to say "this class or 
object is of this type."  It's all made up in the developer's head, and 
there's no way to check compliance of an class interface in Ruby.

	Sean O'Dell