From: "David A. Black" <dblack@...>
Date: 2005-08-17T23:23:28+09:00
Subject: Re: Prototype-based / Ruby question

Hi --

On Wed, 17 Aug 2005, Lyndon Samson wrote:

> I'd say prototype means no classes, that is create an Object from another (
> Including Object ) and munge it at will, add/remove/change behaviour or
> variables.
>
> I wonder if Ruby2 really needs classes? They seem to be de-emphasised in the
> Ruby world ( the one eyed duck is king ) and the other use for class like
> concept is interfaces which there seems to be alot of hostility towards.

Duck typing co-exists peacefully with the existence of classes -- or
at least it can.  The biggest problem I've seen over the years in the
matter of understanding Ruby's particular class/prototype blend is the
"class == type" fallacy.  There are two common consequences of this
misunderstanding.  First, it leads to the creation of new ways of
referring to type (like "duck type", which is redundant and
superfluous).  Second, and sort of the opposite, it leads to the
impression that there's something arcane, wizardly, "evil", and/or
just plain bad about modifying objects during runtime so that their
type is not the same as the type they started out with.

I go for the simplest, most direct account, with no villains in the
story:

A class launches an object into object-space.  Thereafter, the object
has nothing to do directly with its class.  It *remembers* its class,
but it is not constrained by its class.

Instead, an object has a *type*.  (Not "duck type"; just "type".)  An
object's type can change and evolve during runtime.  Because of this
-- that is, both because this is a constant, pervasive, axiomatic
aspect of Ruby, and because it's a source of useful programming
techniques -- it makes sense to treat an object principally on the
basis of its type, rather than its class.  Duck typing encapsulates
this approach.


David

-- 
David A. Black
dblack@wobblini.net