zope's acquisition inheritance

Keith Ray k1e2i3t4h5r6a7y at 1m2a3c4.5c6o7m
Tue Jul 3 17:53:26 CEST 2001


In article <3B41E221.CE23D83E at home.com>, Wostenberg <pwos at home.com> 
wrote:

> 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?
> -Alan

It reminds me of NewtonScript, an OO language without classes, where 
every object had two 'parents' for inheritance, one of which, IIRC, is 
the GUI containment hierarchy... It seems like NewtonScript's direction 
of 'containment inheritance' is opposite of Zope.

I'm not sure how accurate this paper is, but I never programmed 
extensively in NewtonScript, so my memory may be flawed:
<http://www.cc.gatech.edu/~schoedl/projects/NewtonScript/>

"3. Inheritance
NewtonScript uses an inheritance scheme which is derived from SELF. 
SELF's inheritance mechanism is very flexible. For the special purpose 
of writing GUI application, NewtonScript has a simplified double 
inheritance scheme. The two ways of inheritance are very much fixed in 
purpose when implementing windows and dialog controls, but can be used 
more generally as well. 

"3.1 Prototype inheritance
First, each frame can have a prototype frame from which it is derived. 
The mechanism is rather simple, the frame contains a slot called _proto 
and each time the NewtonScript interpreter does not find a slot variable 
or function locally it looks into the frame's prototype and then 
recursively into its prototype until the whole inheritance chain was 
searched through. When a new slot variable is created that already 
exists in a prototype a new slot variable is created in the current 
frame. During lookup this new variable is found first and semantically 
replaces the prototype variable. From a conventional viewpoint 
prototypes serve two roles. First, they are the equivalent to 
user-defined types, to create an instance of the type, you just have to 
create an object derived from the object that defines the behavior of 
your type. Second, prototypes provide the class inheritance mechanism of 
class based languages. 

"The dialog creation mechanism of NewtonScript uses prototype 
inheritance extensively to create dialog items. When a new instance of a 
built-in dialog element is created the new instance has the built-in 
object as its prototype. This object created by the user is then called 
a template in NewtonScript terminology. When this object is then 
actually put onto the screen, the system itself creates another object 
having the template as prototype, with some redefined slots to designate 
view boundaries for example. Thus the template can be reused to create 
more dialog controls with similar properties. 

"3.2 Parent inheritance
The second way of inheritance is conceptually quite similar to prototype 
inheritance, besides the _proto slot a slot called _parent points to 
another inheritance chain similar to the prototype chain. This second 
inheritance scheme is again made to fit into the GUI design, all 
child-windows have a child-parent inheritance relationship to their 
parent windows. An application normally consists of a parent window, 
which is in turn child of the system's root window. All windows and 
dialog controls are then hierarchically ordered below this application 
parent window. Parent inheritance has an effect similar to prototype 
inheritance, variables not found neither in the frame itself nor in its 
prototypes are searched for in the parent frames and their prototypes 
and so forth. Thus slots in the parent window of an application serve as 
application wide globals. Assignment rules are a little different from 
the prototype inheritance rules, you can assign values to slots which 
reside in your chain of parents and grandparents as you can assign 
values to global variables in other languages without replicating these 
variables locally in the current frame. 

"For function lookup, NewtonScript only searches the prototype chain, 
not the parent chain, although a frame can call a function in one of its 
parents directly by dereferencing its _parent slot. It does not become 
entirely clear why this is so, I think it is more because of 
practicality than principle."



More information about the Python-list mailing list