Layers a la PIE/Us

Anthony Hannan ajh18 at cornell.edu
Mon Mar 11 20:25:16 UTC 2002


Jecel Assumpcao Jr <jecel at merlintec.com> wrote:
> Your idea seems very nice, but too static for my taste. PIE and Us 
> allow different layer arrangements to co-exist in memory at the same 
> time. My impression is that you want to use layers like modules in that 
> they patch objects when they are loaded into memory, so there could be 
> compatibility problems.

I guess your talking about being able to look at an object like a method
without installing it.  I didn't elaborate on this but I was thinking we
could look at layers outside of the current image just by looking at
their image segments and interpreting them on the fly without installing
them.  But maybe it would be better to actually load these objects but
not link them to the current image.  This would require using special
"image dispatching" pointers (proxies) in modified fields that return
the appropriate value based on which image is currently active.  I was
hoping to avoid this for performance reasons but maybe its worth it so
multiple images can be loaded simulataneously, even allowing processes
to run under different images at the same time, and allow a process to
switch images/perspectives quickly.  Would you guys like this better?

> One thing I didn't like about Us is that layers are grouped by their 
> layerParent links and the first layer in a list doubles as a 
> "viewpoint" object. PIE has a separate context object for grouping 
> layers so that the same layer can be used differently in different 
> situations (you need to clone the layer in Us to get that effect).

The PIE scheme makes contexts responsible for ordering layers correctly
so dependent layers are loaded after the layers they depend on
(parents).  Since this parent information is in the layers already, I
like reusing that for determining load order.  We are free to add other
independent layers to the parents list if we want to load others layers
before it.  True if we want to reuse a layer but not load the same
parents we have to copy it, but I think this would be rare, plus reusing
a layer under different circumstances is more sophisticated/complex a
concept than just copying and adapting.  Also, having a single layers
concept is simpler than having two concepts, layers and contexts.

> I have found a neat way to implement layers and contexts so they can be 
> used dynamically, but unfortunately it requires a Jitter and won't work 
> on an interpreter.

I would be interested in hearing about your implementation design even
if it requires Jitter.  This would help justify using "image
dispatching" pointers described above.

Cheers,
Anthony



More information about the Squeak-dev mailing list