zope's acquisition inheritance

[David Simmons]

"Wostenberg" <pwos at home.com> wrote in message
news:3B41E221.CE23D83E at home.com...
> This Smalltalker has been studying Zope, the Opensourced python product
> for internet deployment (see http://www.zope.org), to learn.
>
> It has an unusual model of interitance called acquisition, which blends
> class heiarchy with containment. Read
> http://www.zope.org/Members/Amos/WhatIsAcquisition for introduction.
> Basically "objects automatically gather. services from their
> containers.". Everything is potentially a collector-class, and if I drop
> objects into a collection, they inherit behavior from the container.
> Weird, but somehow natural in this Web environment which organises
> content around a tree-structured containment plan.
>
> Anybody heard of acquisition outside Zope, or is it a new contribution
> to OO modelling?

It looks like a special case of delegation/routing to me. The original UI
architecture of SmalltalkAgents (QKS Smalltalk) used a dynamic form of this
to manage routing of handlers and notifications. In 1994 or early 1995 I
generalized it for all objects (it is what we called SemanticMessages).

In SmallScript today this is a fundamental aspect of the property system.
The language provides formal semantics with the ability to declare event
methods, and attach handlers and notification-subscribers to an arbitrary
property type and value.

The actual processing and routing of event-messages is up to the given
receiver. By default it gets routed to its property manager. But in the case
of UI objects they typically override this behavior and route the operations
to a commander (essentially a model) which then can re-route it back as
appropriate (for the layout, script-recording, undo-redo, etc). A prime
ingredient in this is the notion of "routing" methods -- but this is a topic
that requires more time than I want to spend describing now.

Example:

Class name: Foo
{
  event [
  blah
    ...default handler...
  ].
}

eval
[
    aFoo blah.
].

At first blush, this looks like an ordinary message send. But, in fact, the
receiver is queried to handle notifications and provide a handler for the
message. The operation involves an implicit (inquiry) message send (similar
to a perform) to the receiver. The architecture of the SmallScript allows
this to be done without creating any objects during the process (unlike
classic Smalltalk DNU/DNR).

By default the inquiry message is almost a no-op and so is very low cost. If
the object in question has delegation properties then the default mechanism
checks for corresponding notifiers and handlers.

UI components typically redirect inquiry-messages to their commander with
additional annotations. The commander then routes the message (as
appropriate). Where the routing typically goes up the containment heirarchy.
If no commander is available, then the message be routed up the container
heirarchy directly -- depends on which QKS-Smalltalk version we're talking
about.

One can manually invoke the same mechanism in SmalltalkAgents using
#smPerform... or #smNotify... where the <selector> can be any object
(including the virtualized AOS Platform keyCodes). When manually invoked the
receiver does not have to provide an implementation -- which is how the
message typically gets re-routed.

There is also additional ability to provide a block (or in SmallScript an
OUT var) to record whether a message was handled. This requires using the
lower level smDispatch call which offers finer grain of control.

SemanticMessages allow for dynamic receiver, selector, and argument
disposition. Thus one have thread (execution context) specific routing as
well as receiver state based routing.

--
-- Dave S. [ http://www.smallscript.net ]

> -Alan
>
>
>
>
>
>
>
>
>