[self-interest] Re: Interesting question on factoring/clone

Dru Nelson dru at redwoodsoft.com
Wed Sep 15 21:35:51 UTC 1999


[jecel's description of copydown slots and
newtonscript]

Now I read about object sharing "Parents are Shared Parts: Inheritance and
Encapsulation in Self". I skipped this read before since I thought 'I knew
it already' :-).

At any rate, it describes a system having a data parent and a traits
parent. When the prototype is cloned, the proper 'data parent' gets cloned
as well. 
Q. Which one of the papers describes this problem the best?

This leads to the question... why do I care? Well, classes are quite
popular and they do work in some cases. Sometimes, every now and then,
subclassing works fairly well. I wouldn't want to make it a
problem to implement subclassing. I would like to do this
without removing proto functionality as well.

So, lets say I have a prototype and a trait for a parent. This works
great. I clone the prototype and I have something I like. Now, I
"subclass". I create a "newtrait" that uses the trait for a parent.
I create a newprototype with two parents - The newtrait and the prototype
for trait. So, this is fine as well. Now the trick is when you want to
do a clone. You can do two things. You can explicity override clone to
always clone it's 'data parent' which means creating a two parent
structure (like NewtonScript).

Another option is to use annotations to mark specific prototypes as
'clonable'. That way a proto will get it's data parent's when it get's
cloned. The problem with either of these is that it cuts into the 
simplicity of self.

Also, one other thing. All of this assumes that only changes to traits
will be propagated to proto's that use the traits. 
Q. How is this problem handled in Self?

Reply to the original post below. Interesting tidbit, I used to have
a Newton.

I've read the documentation 


>    _proto of cp : p
>    _parent of cp : ColoredPoint
>    _proto of p: ()
>    _parent of p: ObjectPoint
> 
> Now suppose we "clone" cp to create acp. This starts out its
> life as an otherwise empty object with cp as its data parent:
> 
>    _proto of acp: cp
>    _parent of acp: ()

Wouldn't the clone have the same _proto and _parent. (ColoredPoint)
and leave the _proto the same which fits more with the problem.

> This still works ok, as long as acp has the same "color" value
> as cp and the same "x" and "y" values as p. But if we send a
> message to acp that would change one of those values, we create
> a new slot on the fly in acp itself and change that slot instead
> of the parent's slot (this is called "copy on write slots").

I did read up on this again. They designed this structure so that it
worked with their GUI view hierarchy. Still nobody has described it in
this way.

> This is much more dynamic and flexible than Self, but also
> very hard to get high performance with. While Self is optimized
> for speed (no matter how much memory it takes), NewtonScript is
> optimized for a small memory footprint (no matter how slow it
> is) which is reasonable given that the first Newtons had a total
> of 640KB of memory!

 
Much thanks for the reply Jecel.

Many questions...,

Dru Nelson
San Mateo, California







More information about the Self-interest mailing list