Derek Richardson wrote:

I've decided to go ahead and write an RFC 4122 UUID utility based on zope.intid (this is for a Plone SoC project, but this bit is pure Zope 3). I wrote most of it today and there is more code shared between the two than is different. The main differences are:

* OOBTrees, instead of an IOBTree and an OIBTree
* Different events are fired when an object is registered and unregistered (they could be merged, but this is easy backwards-compatibility)
* _generateId() is, of course, different

The rest is pretty much copied and pasted, even most of the tests.

My question is: should the common parts be abstracted out into a framework for id utilities, of which intid and uuid will be two instantiations? I know this is a small amount of code but:

* I hate copy and paste
* I hate the idea of bugs in two places (implicit coupling, from a bug fixer's perspective) * Larger codebases mean more to read to understand what is going on for newbies, like me

Of course, the duplication rule is "If you do it three times, you're doing it wrong" and I've only done it the second time. So, part of this question is whether anyone can see a future need for any id utilities other than intid and uuid. If so, I think this would definitely be a good move. Otherwise, I'm up in the air.

Of course, this would be a change to zope core, which is the main reason I'm leery. I will be sending in my contributor agreement tomorrow. So, I'm really wondering whether this is worth changing in the core or whether we shouldn't bother.

In the spirit of Benji's suggestion, why don't you try to make the UUID utility *use* the intid utility? Basically, the UUID utility would simply keep a mapping of intid <-> UUID and defer to the intid utility for retrieving the object from the intid and viceversa.

Speed might be an issue here, though BTrees are pretty fast and memory efficient, especially with integers...

-- -- Professional Zope documentation and training

Zope3-users mailing list

Reply via email to