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
* _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
* 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...
http://worldcookery.com -- Professional Zope documentation and training
Zope3-users mailing list