WindowFrame design

Jim Benson jb at speed.net
Fri Jul 13 07:19:33 UTC 2001


Lex,

>
> You say "structure" as if it were a bad thing!  It seems better to
> decide how dynamic each property should be, instead of making every
> property completely dynamic.

>From my perspective, duplicating structures is a bad thing. Submorphs are
not 'properties', they are part of the substructure of the morph being
defined, and are already stored in the submorph list. I don't think they
should be cached on a routine basis. I'll go back to the case of the
SystemWindow. I'm not picking on SystemWindow, just using it as a reference
as it seems pretty typical of an evolving morph in Squeak.

There are four buttons on the title bar stored in ivars, closeBox,
expandBox, collapseBox and menuBox. These morphs are also submorphs of
SystemWindow. Each of these morphs pretty much live their lives
independently, that is, they don't rely on outside morphs interacting with
them. As far as I can tell, most of the use of these ivars is during
instance creation (when a local variable could have been used) or in special
cases (which are relatively rare), when a named lookup would be just as
appropriate. I would suggest that the class SystemWindow is not more
informative with their presence.

Obviously I'm not suggesting eliminating ivars from holding morphs
altogether. Ivars are nice for holding the roots of complex morphs, let's
say a view morph and a controller morph. Something along the lines of a
MorphicModel. This affords a conduit for communication between the view and
controller, e.g. the controller morph telling it's owner to change the view,
and because the owner has a cache of the view morph, it can pass the message
along to the view morph directly. I would agree that a property use in this
case subtracts from from fundamental structure comprehension.

Yeah, if I'm talking to a morph all of the time, great, cache it and put it
in an ivar. What I have noticed is that this is done routinely rather than
on an as needed basis. Add a morph, add an ivar to put it in. In my opinion,
this tends to make the morph more complex than need be. Fortunately, most
morphs ivars are simply kept but I think you could imagine the case where
synchronization problems could creep in. It's just a lot of extra work,
storage, and methods for no real benefit.

>Consider: the more optional variables there are,
> the less informative the class of the object is.  The more optional
> variables there are, the more if-then's there will be in the code.
>

I'm not quite sure what you're trying to say here.

I'm trying to eliminate variables, not make them optional. I'll give you
another example. Let's say in our SystemWindow we allow for different
numbers of window buttons in the title bar. Sometimes we allow the
expandBox, sometimes we don't, menuBox the same, etc. In both the ivar case
and the named morph lookup case, you still have to do if-then's to determine
if one is present/absent. I would suggest that it's just more work to keep
them in ivars, as you *always* have to keep track of them even if you never
test for special cases.

I'm probably looking at this from the other way around than you. I've been
trying to think of Morphic as the reification of objects on the screen. When
I look at a SystemWindow on the screen, I can see if it has a close box. If
it has one, I can open an explorer and examine the structures. From that
perspective, there is no advantage in having the close box cached in an
ivar, and for me the less duplicate structures the better.

Jim





More information about the Squeak-dev mailing list