Ah...thanks!
- Stephen
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Anthony Hannan Sent: Thursday, January 30, 2003 12:56 PM To: The general-purpose Squeak developers list Subject: Re: Dynamic Scoping & Context Based Behavior (was: Dynamic scoping)
Hi Stephen,
Your describing perspectives/layers/subject-orientation. See:
[Us] Randall B. Smith and David Ungar. A Simple and Unifying Approach to Subjective Objects. Theory and Practice of Object Systems 2(3):161-178, 1996. http://citeseer.nj.nec.com/smith96simple.html
[PerspectiveS] Robert Hirschfeld and Matthias Wagner. PerspectiveS - AspectS with Context. 2002. http://www-ia.tu-ilmenau.de/~hirsch/Projects/Squeak/Perspectiv eS/Perspec tiveS.html
Cheers, Anthony
"Stephen Pair" spair@acm.org wrote:
One of the interesting possibilities that dynamic scoping might present is that it could be used to set a "behavioral context." Currently Squeak has only one global "behavioral
context"...which is
to say that all objects exhibit the same behavior (roughly
speaking)
under all runtime situations in which any given may find itself.
With some modification to the message binding algorithm and the structure of object memory, I think you could construct a
system where
objects could exhibit different behaviors when being utilized in different runtime "behavioral contexts."
Every object would have some behavior that it exhibits in the global (default) behavioral context. Additionally, you could add behavior (and corresponding state) that an object would only exhibit
when it is
being utilized from within a specific runtime behavioral context.
A real world analogy is that people, when in different
contexts, often
exhibit different behavior.
A good example is a domain object that exhibits GUI
rendering behavior
when utilized in the "Morphic" behavioral context. Upon first utilization in the Morphic context, the object would adopt the rendering behavior and state that you had previously
defined for all
objects of its class. This would eliminate the need to have two separate objects for the model and the view, yet still have
all of the
benefits of model-view separation. Furthermore, if you had
different
morphic applications for which different renderings were
required for
the same domain object, each application could define its own behavioral context (which would each inherit from the Morphic context). Method lookup would first look for methods in
the specific
behavioral context, and then follow an inheritance chain of
behavioral
contexts, with the global default behavioral context being
the root of
this heirarchy.
- Stephen
squeak-dev@lists.squeakfoundation.org
-
Stephen Pair