Jeremy Tregunna wrote:

> I've been working with, and assisting in development of the prototype
> programming language Io for the past 2 years, I'm fully aware of the
> design principals one should utilize when working within the confines
> of a prototype-based language. As far as how people use it; it is my
> experience that those familiar with class based OOP tend to take
> about 3 weeks or so before they start to understand that you don't
> define a template first; you instead define your object, and from
> that make copies modifying as needed. That said however, just because
> it looks like someone is writing in a class-based style, doesn't mean
> they are. Generally speaking quite a few occasions will you find
> yourself cloning an object which seemingly is acting like a class
> (not being used itself except as a template for other objects). In
> cases like this, I don't know what your problem is; this comes up
> quite a bit, and is often the simpler of the two choices --
> reconstruct the object based on all previous objects, or construct a
> template holding basic values which then a few objects will clone
> from. If you have a system like Io or NewtonScript which use a
> differential inheritance model, only the changes from the object you
> are cloning will be attached to your object, so you can change this
> template at a later time, and anything that any object that cloned
> from it hasn't changed, will receive those changes as well when
> they're used. To be honest, I think this satisfies a lot of
> conditions. Nobody is saying that class-based programming is without
> its merits, and certainly writing in a seemingly class-based style in
> a prototype language is possible, and often the simpler case.
>
> To address your dog point more directly, incase I have to spell it
> out for you. It is often the case where you have say a Kennel which
> in this case, let's think of it like a data structure that houses
> only Dog-like objects. It is more efficient to define (in a system
> like Io or NewtonScript at least) a singular Dog object, and then
> define dogs from that. I.e.,
>
> Kennel := Object clone
> Kennel dogs := list
> Kennel addDog := method(aDog, dogs atIfAbsentPut(aDog))
>
> Dog := Object clone
> Dog newSlot("colour")
> Dog newSlot("size")
> Dog newSlot("kind")
> Dog newSlot("name")
>
> /* newSlot creates a setter slot and a value slot */
>
> Now, if you're Kennel is going to house a lot of Newfoundland dogs,
> it may be worth while to make a clone of Dog called NewfoundlandDog
> (or similar); unless of course, a very small minority are going to be
> anything but NewfoundlandDog's, in which case, I'd make Dog above
> representative of a newfoundland (setting "kind" to "Newfoundland")
> then for any non newfoundland types, i'd just as an example:
>
> Fred := NewfoundlandDog clone
> Fred setKind("Malamute")
> ...
>
> And similar for other dogs (cloning Fred for other Malamutes, etc).
>
> It makes sense in a differential inheritance system to do this kind
> of thing since it eliminates a lot of repeating.
>
> That said, I understand ruby doesn't have a differential inheritance
> system, but these decisions can be applied to Ruby when using a
> prototype design pattern. It just makes sense; the nice thing is,
> it's not required, which is what differentiates it from class-based
> programming.

I think maybe you took what I was saying for more than my intended
point. I was only sayng that I think the use of the word "Prototype" in
Ara's implementation conveys too much the prior notions of class-based
OOP, and that the more general term, 'Object' would be more fitting.
Then I was trying to explain why.

Interestingly, your example uses the very word 'Object'.

Other than that, I understand and agree with everything you are saying.

T.