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

Jecel Assumpcao Jr jecel at lsi.usp.br
Thu Sep 16 17:54:46 UTC 1999

Dru Nelson wrote:
> 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' :-).

Inheriting data is something that doesn't seem very useful until
you have actually tried it for a while. That is why so many people
don't see why Self would be more interesting than Smalltalk.

> 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.

I don't think there is any example of code that works like this,
but it is easy to do in Self by creating your own clone method
(as you described below).

> Q. Which one of the papers describes this problem the best?

Are there any others besides "Shared Parts" for Self? For
prototype languages in general, this one is great:

  [DMC 92] Christophe Dony, Jacques Malenfant, Pierre Cointe :
  "Prototype-Based Languages: From a New Taxonomy to Constructive
  Proposals and Their Validation", Proceedings of ACM OOPSLA'92 :
  Vancouver, Canada. Sigplan Notices, Vol. 27, No. 10, pp. 201-217,
  October 1992.

> 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.

Agreed, and the "copydown slots parent" annotation is much too
awkward. I want to keep things separate and dynamic - if I wanted
to bunch all the slots in huge objects I'd be programming in
Kevo :-)

> 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.

But note that you are inheriting "trait" twice in newprototype
(once through newtrait and once through prototype). This is
normally not a problem, but makes it much easier to get
"ambiguous selector" errors.

> 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.

Certainly an option. While it is good to avoid this kind of
reflection as much as possible, "clone" is already as reflective
as it gets...

> 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?

I am not sure I understood your problem. Are you worried about
changes to the original "data parent" not affecting the data
parents of any cloned objects? The problem is that sometimes
you might want the changes to happen everywhere but in other
occasions you want the changes to by limited to the original
data parent. It is hard to design a system to make a choice
automatically. The current Self system only handles the
second option (clones aren't changed) directly.

> Reply to the original post below. Interesting tidbit, I used to have
> a Newton.
> I've read the documentation

I've never used a Newton or seen the documentation, so you shouldn't
take anything I say about it too seriously.

> >    _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.

"acp" is *not* a clone of "cp" in Self sense at all - you are
totally correct about that. But it does "look" exactly like cp
to anyone sending messages to it, so you might think of it as
a "virtual clone". Both real clones and virtual clones have
their uses (but except for their memory layouts, they work
exactly the same if all data slots are "copy on write").

Sorry to be so confusing, but it is a confusing world out there :-)

-- Jecel

More information about the Self-interest mailing list