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