[Grok-dev] Re: Performance of OrderedContainer
gary at zope.com
Wed Jun 18 07:26:08 EDT 2008
On Jun 18, 2008, at 4:11 AM, Martijn Faassen wrote:
> Gary Poster wrote:
>> On Jun 17, 2008, at 1:58 PM, Gary Poster wrote:
>>> It can be a drop in replacement for PersistentList in an ordered
>>> mapping implementation. The only potential incompatibility I can
>>> think of is that getting a slice returns an iterator rather than a
>> Heh, no reply to this,
> [snip caveats with zc.blist in this role]
> Thanks for the feedback, Gary, it is appreciated.
Thanks for your reply.
> The problem is that indeed grok.OrderedContainer does implement the
> zope.app.container API for ordering, if I'm not wrong.
> Anyway, it would be good if someone could introduce a patch with a
> more scalable OrderedContainer for Grok *before* the release, as
> it'll be harder to change internal data structures after people
> start using it. Not impossible of course, just a lot harder.
> For inspiration, we need to study
> We also need to investigate whether blist could be made to make
> sense i this role after all.
I just glanced at it. The API they have (with deltas and such) would
work well with blist. The adapter/annotation approach would also
allow plug-in replacement with a blist approach, should such be desired.
The default implementation of the ordering adapter in this file uses
PersistentList (see _order near the bottom), so without a different
adapter, I disagree that this implementation would be appropriate for
very large collections.
With a different adapter, the API looks good to me, and I like the
adapter idea for providing ordering. Unfortunately, the license is
LICENSE.GPL), so the API itself may be tainted (or not, no idea, but
my lack of ability to know is part of the point). I thought code in
the "plone" namespace was supposed to be ZPL, and "plone.app" was
GPL? If it were ZPL, it could potentially just be snarfed up directly
by grok, IMO.
More information about the Grok-dev