> > Me writes: [Morphs seem] like the perfect opportunity for
> > multiple inheritance, doesn't it? Put the shared properties in
> > a `graphics parent': [code elided ... ] Anything wrong with this?
> 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 ... ;-). Seriously. Why? We'd have at most one state
object per morph. If we have hundreds of morphs, then so be it.
At the moment, I'm not sure, but every button in a menu has its own
color in the current system, doesn't it?
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.
> 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.
By the way, I just realize that I have made the color slot
constant, I meant to make it writable, to allow for corrupting
proto... ahem, *cough*, to allow to change the shared state.
More precisely:
(globalGraphics _addSlots:
(| normalText <- (| paint <- paints black.
font <- fonts times. |).
normalBackground <- (| paint <- paints grey. |).
... . -- More faces and paints
|).
_addSlots:
(| aGroup = (| graphicsParent* = globalGraphics. |). |).
aGroup _addSlots:
(| leftSide = (| graphicsParent* = aGroup.
parent* = traits fooMorph.
... . -- leftish stuff
|).
rightSide = (| graphicsParent* = aGroup.
parent* = traits barMorph.
... . -- rightish stuff
|).
... .
|).
)
> 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.
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).
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.
> Another problem with using static inheritance is
> that most objects will be created by dragging morphs
> around with the mouse, not by typing in expressions
> like your example. These automatically generated
> objects will be harder for the user to understand.
I disagree. Menu buttons share color, we should reify that. They
should share state and this should be visible to the user.
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?
Rainer