On Nov 5, 2007, at 11:36 AM, Patrick K. O'Brien wrote:

> While I agree with you in principle, I would be concerned about the
> performance impact of this change (having to reference self).  I've
> got some very big Durus databases that need to be as fast as
> possible.  So if this change would have a negative impact on that,
> I would suggest overriding in your subclass those handful of
> methods that you mentioned.  Fortunately, it wouldn't be very much
> code on your end.  Even if it is less elegant than your suggestion.
>
> Just my opinion.  Sometimes speed is a higher priority than code
> elegance and flexibility...  :-)

The impact on speed of one more self lookup is extremely low relative to
the other things going on.  That's not the problem here.

There is a problem though, and it is that this would break existing
code.
We have subclasses of PersistentList that have data_is values that
don't work as constructors:  they just add on the additional requirement
that the elements of the list are of a certain type.

> Here is another thought.  Durus could have a base class
> (PersistentListBase) coded as you described, that you could
> subclass, and the Durus PersistentList could inherit from
> PersistentListBase and override certain methods with the current
> code which is optimized for speed.  That would give you the best of
> both worlds, but would be more work for the Durus folks.

I don't like the idea of adding any complexity or risk to make this
fairly exotic extension a little bit easier.

> Of course, all of this is without knowing the actual performance
> characteristics of the proposed change...

I'm curious, though, Andrew.
What is the objective of your list subclass?