Derek Richardson wrote:
Philipp von Weitershausen wrote:
Derek Richardson wrote:
I sense that I'm missing the point here. Perhaps you can elaborate on what you mean when you say "use" and "collaboration." I usually know what those terms mean, but I'm not sure I am getting it in this context.

The paragraph definitely seems to miss the point, so let me speak code::

  class UUIDUtility(Contained, Persistent):

      def __init__(self):
          self.uuids = IOBTree.IOBTree()
          self.intids = OIBTree.OIBTree()

      def getObject(self, uuid):
          intid = self.intids[uuid]
          return getUtility(IIntIds).getObject(intid)

      def getUUID(self, object):
          intid = getUtility(IIntIds).getId(object)
          return self.uuids[intid]

I'm omitting several seatbelts and various functions to add/remove objects from the UUID utility, but I hope you'll get the idea.

With the composition approach, the actual utility class may be a little shorter than simply copying the whole thing, but I'll still have to copy and just change the names on a bunch of stuff in (IIntIds -> IUUIDs, IIntIdsQuery -> UUIDSQuery, etc).

Perhaps. You could also come up with a shorter/easier/... API, though I see how it is compelling to model after the IIntIds API.

And I'll have to copy most of the tests.

You better have good test coverage for your utility anyway. That argument doesn't count :).

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.

The subclasses are pretty much complete as written here and the BaseIdUtility is just a minor abridgment of IntIds. This allows all the interfaces (other than the two empty markers and the events) to be reused between intids and UUIDs and most of the tests can be performed for both, as well.

We've talked a lot about the composition alternative to my idea, but we haven't talked about my idea much. What is suboptimal with the way I'm proposing, other than that it requires changing zope core? Or is that a good enough reason to not do it?

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.

-- -- Professional Zope documentation and training

Zope3-users mailing list

Reply via email to