[Zope] Pointer-to-Object Properties

[Brian Lloyd]

> > It would be very beneficial to be able to 'point' to 
> > arbitrary objects as if they
> > were sub objects, thus enabling one-to-many, many-to-one, and 
> > many-to-many
> > relationships not constrained by the object heirarchy.
> > 
> > Classic example: Many author objects, many book objects. 
> > Authors can have written
> > several books, and certain books are collaborations with more 
> > than one author. It
> > does not make sense for books to be contained within authors, 
> > or authors to be
> > contained within books.
> > 
> > While this simplistic scenario would allow us to either 
> > assign a list property
> > with  book titles to an author object, or a list property 
> > containing authors names
> > to a book object, and live with the small amount of 
> > duplicated data

I'd like to jump in and play devil's advocate for a moment. Note
that this is not to necessarily refute the idea of pointer-to-obj
properties, but more to start brainstorming and to help me get a
better idea of the core problem here...

Historically (or hysterically, as Jim would say) properties have
had some basic traits that distinguish them from "subobjects":

  o They are generally "simple named values" of simple types.

  o Being simple types, they have either no or very limited behavior.

  o They have somewhat less of a sense of "identity" than full 
    Zope objects.

  o They are not protected individually by the security machinery.


So to summarize, properties were really designed to be supporting
players rather than lead actors on the Zope stage - they should
be thought of as metadata about an object more than as objects
themselves in most cases.

Looking at your books and authors example:

  > > Classic example: Many author objects, many book objects. 
  > > Authors can have written several books, and certain books 
  > > are collaborations with more than one author. It does not
  > > make sense for books to be contained within authors, or 
  > > authors to be contained within books.

The important thing in this example is the relationships, not
the actual "place" of the objects. From a design perspective,
the details of where the actual objects come from would be
best hidden behind a set of interfaces anyway:

  # get a book object
  theBook=someMethodToGetABook()

  # get a list of author objects
  authors=theBook.getAuthors()

  for dude in authors:
    books=dude.getBooks()

Having interfaces like these would give you an extensible
architecture - books and authors could later come from a
relational db or other source as the system grows.

The core problem (it seems to me) is that Zope currently makes
it hard to do the many-to-many relationships that are needed
behind the scenes to implement these interfaces.

Rather than do a lot of work extending the meaning and 
capabilities of properties, it seems to me that this could
be handled if we had some sort of "reference" object. What 
if, for example, you could do a "copy" on an object then go
to some other folder and do a "paste reference"? Assuming 
we had this, you could implement your interfaces over a
Zope design where you have 2 Folders: "Books" contains
Book objects and "Authors" contains Author objects. 

Both Book and Author objects would be ObjectManagers. Though
a Book would never contain an _actual_ Author object directly, 
it could contain any number of _references_ to Author objects
and vice versa. A Book object's getAuthors interface returns a 
list of Author objects - these could be obtained either by sorting
through objectValues on the Book itself or, better yet, each 
Book may have a Folder "Authors" which it uses as a collection 
to store Author references.

Such a design would (IMHO) have a number of advantages over 
going the property route. You would have much more flexibility
in designing your system because you could traverse right through
a book into its author, use acquisition and all the other benefits
of the containment heirarchy. Perhaps most importantly, you would
have fine-grained access control over the objects (properties would
be all-or-nothing).

While there would be some issues to work through in implementing
reference objects, I suspect it would be much less than would be
required to make properties meet your needs. There is also some
amount of prior thought that has gone into this; the IETF WebDAV 
working group has been working on a "bindings" spec and they
have a pretty decent object model that has come out of dealing 
with all of the issues of bindings/references. I've found that
model to be a good place to start when thinking about bindings
in Zope.

Well, I've rambled on long enough - let me know if any of this
has the ring of truth to you or if you think I'm totally missing
the point...



Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com