Re: ports and morphs

[Jecel Assumpcao Jr <jecel@lsi.usp.br>]

Rainer Blome wrote:
> > Jecel replies: The problem is that you will create hundreds of
> > twisty little objects, all different. ...
> 
> Twisty :-).  Writhing, slippery, fishy, swarming all over the
> system ... ;-).

An old Adventure joke from the days of Fortran... don't
worry about it :-)

>  Seriously.  Why?  We'd have at most one state
> object per morph.  If we have hundreds of morphs, then so be it.

If you have hundreds of morphs that are clones of just a
few prototypes, then you will have few maps and your code
cache will have few entries to run your user interface. If
these morphs have different parents, then you will have as
many maps as "normal" object and your code cache fill be
overflowing with essentially identical customizations of
each method.

We shouldn't have to worry about such implementation
details when programming in Self, I'll agree. But if you
want an interactive user interface, you will have to take
them into account (at least for now).

> At the moment, I'm not sure, but every button in a menu has its own
> color in the current system, doesn't it?

Yes, as well as its position and other information.

> But the intent is to share, so there will be by a large factor less
> of these shared state objects.  The hierarchy that reflects the
> sharing of graphic state is different from the traits hierarchy and
> this should be reified.  The `second' parent slot of NewtonScript
> is intended for (although not restricted to) exacly this purpose.
> For example, all labels should indirectly (via their containers)
> inherit from the same text color object, of which there are only a
> handful, e.g. normal, highlight, bright, alert and dim.

NewtonScript allows copy-on-write slots, which are a bit more
dynamic than what we have in Self. Since that system is a pure
interpreter (as far as I know), it can get away with that
sort of thing.

But I like to use inheritance to like the Model and the View
in a graphic system. It seems neater to have a listView *be*
a list rather than including a reference to one. It makes
the gui "less deep", more direct.

> > In fact, this is just an implementation of the wrapper idea.
> 
> I don't see that.  I didn't mean the enclosing object to denote a
> wrapper, the graphicsParent was to be a shared part.

I know. But you can "wrap" a red color object around a circle
and a rectangle object or you can wrap a circle object around
a red color and a blue color object. A good framework should
probably allow both. In that case, it might make as much
sense for rightStuff to inherit from graphicsParent as the
other way around. So it is a little like wrappers even if
your example doesn't look like it.

> > This becomes much easier to see if
> > you use dynamic inheritance: ( | graphicsParent* <- ... .  |)
> 
> Certainly, you're right, that's what I meant.  At least, sort of.
> Normally, you don't need to rip buttons out of menus, so you don't
> want to pay for it, so you statically inherit from the menu's
> graphicsParent.  If this requires a more elaborate implementation
> to be efficient, so be it.

Once again, implementation issues are influencing design issues.
You want to use constant parent slots to avoid the horrible
costs of dynamic inheritance but then pay other costs because
of code cache overflow.

> When you do rip a button out however, you are doing something
> very unusual, and you are willing to pay for it.  Which, in this case,
> means, you replace the static graphicParent slot by a dynamic one,
> paying for the overhead of moving the object to a new clone family
> (hopefully shared with other `detached' buttons).

You could replace one constant parent with another constant
parent, but I like your idea better. 

> Maybe this works with current Self, maybe it won't, but it would
> with the right Self implementation.  I just want to know which is
> the right thing, in practice worse sometimes does better, though.

This works, of course, since it sticks to the currently defined
semantics. It just doesn't work very well for the reasons I have
already mentioned. You are right that things might be different
in other implementations. A pure interpreter would have less
problems with very dynamic things, for example (it would be
equally bad at everything ;-)

> BTW, I don't think of these systems as languages, I always have the
> objects (i.e. dragging) in mind.  Consequently, I never know how to
> best code a description of a graphically easily created object.  A
> messy issue anyway, what a literal object description means.  Now,
> it describes the structure (declarative?).  Would describing the
> creation (procedural) be better?

I think that creation descriptions would be equally hard to
understand, unless they could be linked to some kind of
animation. 

-- Jecel