zope's acquisition inheritance

[George Jempty]

Keith Ray <k1e2i3t4h5r6a7y at 1m2a3c4.5c6o7m> wrote in message
news:k1e2i3t4h5r6a7y-E9623E.08532703072001 at news...
> In article <3B41E221.CE23D83E at home.com>, Wostenberg <pwos at home.com>
> wrote:
>
> > Anybody heard of acquisition outside Zope, or is it a new contribution
> > to OO modelling?
>
> 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."

Fascinating thread.  I've used a little Python in my day, but what drew my
attention is some similar Javascript functionality.  An outline of a
presentation I gave to Colorado's "FROST" (Front Range Object Study) group
can be found at http://js.inetsw.com/frost_jan2002/

Of particular interest is the second page.  Here is the code from the
library that is used, it's very elementary but demonstrates the idea:

//
//
function NumberExam(fieldVal)
  {
  this.val = fieldVal;
  this.wholeNumExp = /^[1-9]\d*$/;
  this.isWhole = this.wholeNumExp.test(this.val);
  }

function ArabicNumExam(fieldVal)
  {
  this.incorporate = NumberExam; this.incorporate(fieldVal);
  }

And the calling code:

function Convert2Roman(field)
  {
  this.val = field.value;
  var IsValid = new ob.ArabicNumExam(this.val);
  if (!IsValid.isWhole || this.val > 3999)
    alert('Please try again with a whole number between 1 and 3999')

else........................................................................
......................
//
//

As can be seen, the ArabicNumExam constructor gets the 'isWhole' attribute
from the NumberExam constructor.  This functionality is not unknown within
Javascript circles, but there is no agreed upon name for it: I for instance
called it 'incorporation', but acquisition it will be from now on!