...

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