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):
self.uuids = IOBTree.IOBTree()
self.intids = OIBTree.OIBTree()
def getObject(self, uuid):
intid = self.intids[uuid]
def getUUID(self, object):
intid = getUtility(IIntIds).getId(object)
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 interfaces.py (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.
http://worldcookery.com -- Professional Zope documentation and training
Zope3-users mailing list