[Zope] Pointer-to-Object Properties

[Michael Bernstein]

Brian Lloyd wrote:
>  
> 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...

Understood, thanks for the input...

> 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.

Exactly. Thanks for the clear summary.

> 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.

With you so far.

> <description of references as contained objects snipped>
> 
> 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 traversing into referenced objects is attractive, acquisition in this case
is a two-edged sword. If authors ordinarily acquire a method or property from
somewhere 'above' their actual location, traversing into an Author from a Book
could cause the Author to acquire the wrong method or property.

Extending properties to allow traversal into a referenced object appears to be a
convenient breakpoint for disengaging acquisition and security. We do not
necesarily want someone with manager access on a Book to be able to change an
Authors contact information. Since the management interface supports the basic
model of 'customers who have customers', breaking this model for the sake of
many-to-many relationships seems a poor trade-off.

I would think that by going the properties route, all security settings would
derive from the objects context within it's actual location, and that the
referencing objects context would be completely inapplicable.

How is this issue going to be handled with the proposed Topics? Topic objects
are supposed to present an 'alternate' containment heirarchy, will they allow
overiding a contained object's security settings?

> 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.

I'll check it out.

> 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...

I don't think you're missing the point, and I found your input to be very
valuable, but I don't think that Acquisition is always a Good Thing.

Michael Bernstein.