[Morphic] About worlds

Andreas Raab andreas.raab at gmx.de
Sat Aug 16 16:42:03 UTC 2003


Hi,

> Andreas Raab <andreas.raab at gmx.de> wrote: 
> > One way to get rid of the implicit notion of the "active 
> > world" would be to define that a morph is ALWAYS in some
> > world, unless it has been "destroyed" by an interaction
> > or command which clearly denotes that we're not intending
> > to use this guy ever again. The way in which the world 
> > could be associated with some morph might be that the
> > "owner" of some morph cannot ever be nil unless that
> > morph has been destroyed. So the owner chain would uniquely
> > identify which world a morph is in, and the submorphs of 
> > some morph would identify that the morph itself is "present"
> > in this particular arrangement (regardless of whether the
> > container is present in the arrangement of its own container).
>
> I understand the problem, but you're implicit about the solution - do
> you mean that instead of todays remove we would change the 
> Morphs parent to be the world?

No, what I'm saying is that the "owner" relationship should not be affected
at all when you "remove" a morph. In other words, a morph "remembers" what
its owner used to be and this information can be used for a variety of
purposes (including that of retrieving its world).

> > hideScrollbar
> > 	scrollBar close. "get rid of it"
> > 
> > showScrollbar
> > 	scrollBar open. "open it again in the container it used to be in"
> IIUC, these would not change the parent ownership, and therefore be
> reversible.

Yes, exactly.

> > What I am mostly interested in here is: Does anyone see a 
> > significant conceptual problem in the above? I don't _think_
> > I am overlooking anything important here but I'm interested
> > in what other people think about an approach like this.
>
> IIUC, you're saying that world is an attribute derived from the parent
> attribute, and to make world non-optional for visible morphs, you make
> parent non-optional. Without knowin a whole lot about Morphic, this
> sounds ok to me. BTW, why would it break everything?

Because the fundamental invariant we preserve these days is that if a
morph's owner is non-nil the morph appears in its submorphs. IOW, the
following must always hold:

	aMorph owner
		ifNotNil:[aMorph owner submorphs includes: aMorph].

If this invariant is not preserved, all hell will break loose. Trust me ;-)
All of the messages which are upcast along the owner chain would have to be
fixed which includes some that are critical in terms of speed
(invalidations, layout).

Secondly, there is a significant problem when creating new morphs. These
days, new morphs are not initialized in a definitive context (e.g., when
they are created their owner is nil) and one would need to provide
appropriate initializations. Most places don't care about this at all and I
would suspect that we'd get into serious trouble if we started relying on
all morphs being properly initialized ("properly" as in: having a definite
link to some world unless destroyed).

Cheers,
  - Andreas



More information about the Squeak-dev mailing list