Philipp von Weitershausen wrote:
Martin and Gary pointed out other good reasons why not to go with
subclassing: the standard intid utility doesn't work in all
environments. Apparently in Zope 2 you'll need a slightly differnet
implementation. If you just defer to it via utility lookup, your UUID
utility might actually work on both platforms, as long as there's an
intid utility. It makes things more flexible.
Hmmm. I've looked in Zope 2.10.3 final (the earliest release I may
target) and zope.app.intid is the same between Zope 2.10.3 and Zope
3.3.1, except for the presence in 2.10.3 of
zope.app.intid-configure.zcml, which is just a slug. Am I looking in the
Your subclassing idea has a lot of appeal to it. To answer your question
what's suboptimal about it: you'll have to wait till the next Zope 3
release cycle to actually make use those modifications. Also, like I
said above, the composition approach allows you to be more flexible.
OK, yes, this is a problem. I'm targeting on Plone 3.5 (for the final
product, not the uuid utility alone), but I'd like to be
backwards-compatible with Zope 2.10.x. So, yes, I'll have to provide a
complete backwards-compatible package.
I've thought about it and decided that these two proposals (subclassing
and composition) are partially orthogonal. Half of subclassing is simply
genericizing the interfaces; composition is a matter of implementation.
For proof, consider that we could have a UUIDs that implements IIDs and
defers to an IntIds for implementation, which also implements IIDs. This
might reduce the benefits of code reuse, but would still gain the
benefit of one set of interfaces (aside from the IntIds and UUIDs markers).
So, my plan. I am going to copy IntIds, genericize the interfaces, and
split the superclass from the subclass as mentioned. I'm going to do
this in my package. I will provide a UUID implementation but not an
IntId implementation. That way if, in the future, y'all decide to move
towards this in the core, there will be a pre-existing implementation
and I'll be ready. You could include just the interfaces, the interfaces
and the utility superclass with a new IntIds subclass without the UUID
implementation, or you could include everything - it's up to you. And,
if you don't, then I haven't lost anything but 15 minutes of time.
As for implementation, I'm going to have to think through whether
composition is appropriate for my use. Another advantage of genericizing
the interfaces is that this is an implementation detail - I may provide
two uuid implementations, one that is composed by intid and one that is
not. I may also rethink the implementation of the base utility class to
see if I can maximize reuse between these two cases. And, having this
flexibility will help me later if I run into trouble backporting to Zope
2.10.x. A fun project!
The code will be in the Vice project in the Plone collective, for now,
in the packages collective.id and collective.uuid.
Zope3-users mailing list