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.

Zope3-users mailing list

Reply via email to