John Anderson wrote:
On the collections API, you've switched a create at construction time
model. Does this mean it will be impossible to restructure the
collection tree, short of destroying a subtree and constructing an
entirely new one?
Yes, that will be impossible without destroying and re-constructing.
The way the code was written before wouldn't have worked anyway, the
hard part here is that when a collection tree is modified in place, a
large, potentially huge, number of notifications have to be sent
around (at least to maintain upstream indexes). None of that was in
place in the old code, except for the add/removeSource method in
collections.py, which is still there and still works as before. Once
we have a use case for such in-place collection structure
rearranging, beyond what is implemented and functional today, we can
reconsider this.
I think we could get away with not sending any notifications when
rearranging the collection tree and recompute everything after the
rearrangement. Independent of whether or not the old code actually
worked, I suspect not allowing rearrangement will end eventually end
up biting us, but I don't think we should work on it until we end up
with a use case.
+1 - trying to optimize for rearranging/restructuring the collection
tree seems...well, non-optimal. We currently have no use case or
requirement for this. The way-off-in-the-future rule builder is about
the closest thing to a use case than I can think of, and I don't think
it would suffer from destroying/recreating a collection tree.
Alec
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
