[Zope3-Users] Re: zope.intid and UUIDs

[Gary Poster]

On Apr 19, 2007, at 12:56 PM, Derek Richardson wrote:
> We've talked a lot about the composition alternative to my idea,  
> but we haven't talked about my idea much. What is suboptimal with  
> the way I'm proposing, other than that it requires changing zope core?

Martin Aspeli had some concrete things to say about why subclassing,  
your proposal, is suboptimal in comparison to composition.  He cast  
it as "why composition would be better", which is simply the mirror  
image.

His first point is particularly interesting: the composition approach  
might let Plone users leverage your code, which introduces it to a  
large community of users.  They (or Zope 2 core?  not sure) have  
their own intid utility.

Composition will be simpler, both in the short and long term; or, if  
you prefer, to relate it to your proposal, the subclassing approach  
is suboptimal in comparison.

Some more thoughts, FWIW:

- I suggest that the implementation should be hidden away.  One  
should be able to adapt an object to something like IUUID or  
IUUIDProvider.  That way we can implement a variety of solutions,  
including a direct key-reference-to-UUID mapping, a intid-to-UUID  
mapping, a simple annotation, or other approaches.  In other words,  
IMO, the main feature of your package should be an interface (or two,  
see below).

- I imagine you also want to be able to find objects for a given  
UUID.  I'd suggest an interface for that, which is used to look up a  
utility.  Again, the implementation may vary.

- In terms of your default implementation, the integer-based approach  
is interesting as a building block because there may be different  
integer sources for a given object, not just intids.  For instance, I  
have an app in which I have integer identifiers for virtual objects,  
which may be fulfilled with different real objects based on current  
state.  One app might want UUIDs to be generated for the virtual  
object, while another might want UUIDs for the "real" objects (so  
intids based on the standard persistent object key references would  
be appropriate).

> Or is that a good enough reason to not do it?

No, but that certainly raises the bar, as you'd expect.

Gary