Consilidating BTree types (was RE: [ZODB-Dev] Fwd: [Zope3-dev] directory hierarchy proposal (Martijn Faassen))

[Tim Peters]

[Casey Duncan]
> Perhaps they *should* be exposed as single functions which front
> for specific implementations for each BTree type. That is the "union"
> function checks its operand and calls the proper btree union code.

The current code organization doesn't really support this possibility:  the
BTree code is compiled 5 separate times, each time defining a bunch of
macros differently.  That's where the 5 different XY*** flavors of BTree,
Bucket, Set and TreeSet come from.  A consequence is that, e.g., the
IIBucket code can't "see" the type of an IOBucket:  "the IIBucket code" is
invisible to "the IOBucket code".  Similarly all the IO types are invisible
to all the OO types are invisible to all the OI types, etc.

For example, where multiunion_m() has the line

    result = BUCKET(PyObject_CallObject(OBJECT(&SetType), NULL));

there isn't any *common* SetType struct:  there are 5 distinct SetType
structs, and the one multiunion_m() *sees* changes during each of the 5
times multiunion_m gets compiled.  Similarly, the expansion of BUCKET
changes each of the 5 times too, and the expansion produced by compilation
#i isn't visible to any code in compilation #j for 1 <= i != j <= 5.

The bottom line is that making this "simpler" isn't trivial.  That doesn't
mean it couldn't be done, but I don't think it's a 10-minute project, so it
has to get judged on a bang-for-the-buck measure.

> ...
> This also brings up another point that I recently encountered
> (vicariously through Shane). It is currently quite difficult for an
> application to discern whether an object is from the II, IO or OO
> families.

You mean it's hard to tell whether an object is from the union of those
families, or that it's hard to tell which of those families an object is
from given that you already know it's from the union?  The latter is doable;
e.g.,

>>> o
<OOBTree object at 0x008D9B18>
>>> isinstance(o, BTrees.OOBTree.OOBTree)
True
>>> isinstance(o, BTrees.OIBTree.OIBTree)
False
>>>

> Perhaps a common abstract base class for each btree type
> would be helpful...

As above.