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

Ah.  I completely misunderstood your angle -- I thought you were trying
to make major rewrites of SystemWindow be easy, even if the result isn't
as nice.  Instead, you are trying to eliminate redundant instance
variables--this is certainly a wonderful goal!


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


You seem to know this code more than I do, but at a glance it's not
completely obvious that closeBox, et al, are unneeded.  Using inst var
refs, I see:

	closeBox	 - 	after SW creation, the closeBox gets enabled and disabled
every once in a while.
	collapseBox - ditto
	labelString - needed to relabel the window after it's created
	


The alternative, I suppose, is to go searching through submorphs looking
for an item.  This has some appeal -- it does eliminate a little
redundancy, and it means you can dissasemble and re-assemble morphs more
freely.  However, how should the seerch be done?  I guess I'll have to
reread your proposal, but for things like closeBox which will always be
there, making it more dynamic doesn't seem like a big win.  I guess it
*is* pretty neat if you can drag off the close button of a window to
make it harder to close, and that you can later add any old close button
back to a window and that close button will work (for this latter, one
will want to search owners, not submorphs!).

Neat stuff. 


Lne of code of the day:

	Preferences noviceMode ifTrue: [m lock] ifFalse: [m lock]


Heh :)

-Lex