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

[Derek Richardson]

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 
wrong place?

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

Thanks,

Derek