Exploring Zope

Bijan Parsia bparsia at email.unc.edu
Thu Oct 30 15:06:51 UTC 2003


On Thu, 30 Oct 2003 goran.krampe at bluefish.se wrote:

> John Maxwell <jmax at sfu.ca> wrote:
> > ducasse wrote:
> >
> > > could you tell us a word or more ;) on acquisition?
> >
> > Thanks Eric for the detail...
> >
> > The real short answer is: out of the box, Zope gives you two kinds of
> > inheritance. The first is regular class inheritance; the second is
> > acquisition, which, in the webserver metaphor means that if I have an
> > object (an image, for instance) available in the namespace at the top
> > of the hierarchy, I can refer to it "locally" six folders down. This is
> > incredibly handy for web work, because, for instance, you can build a
> > single navigation system at the top level and simply refer to it all
> > the way down the tree. Zope's built-in security/access model lends
> > itself really nicely to this, too.
> >
> >   - John Maxwell
> >     jmax at sfu.ca
>
> I haven't followed this thread more than "casually" but it just occurred
> to me that HttpView has a similar mechanism. When a request is processed
> by the HttpView framework a chain of HVHttpView subclasses are chained
> together with parent pointers. Each view typically maps to a "directory"
> in the url.
[snip]

It all sounds like NewtonScript's "parent" inheritence. So, NS had two
sorts of inheritence, "proto" (analogous to class inheritence) and
"parent" (and they interacted in an interleaved, "comb" like way).

Hypercard inheritence was like this too.

My recollection is that it was incredibly handy for direct manipulation
GUI style work. There are some very good NewtonScript papers. Hmm.

A bit here:
	http://wsmith.best.vwh.net/Self-intro.html

And there may be something on:
	http://wsmith.best.vwh.net/works.html
Ah, yes:
	http://wsmith.best.vwh.net/OOPSLA95.pdf
Talks about "container" inheritence.

I don't see any of the famous inheritence comb diagrams, but I'm sure
there's some somewhere in all them links.

Cheers,
Bijan Parsia.




More information about the Squeak-dev mailing list