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
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
