At 11:57 AM 5/16/2006 -0700, Andi Vajda wrote:
On Tue, 16 May 2006, Phillip J. Eby wrote:
To answer Grant's question, this does not actually keep Kind composition
"under the covers" - it's based purely on the annotation
system. Annotation attributes are normal attributes, so they should be
as indexable as anything else. However, if performance considerations
show that storing stamp types as a set (e.g. as shown above) is
detrimental then some other way of tracking active stamps is needed.
If everything is of the same kind, the kind query is going to be a lot
less useful. Currently, the kind query is used a lot...
In that case, it seems like a slightly different implementation using one
refcollection per stamp type would do the trick. The add() and remove()
would have to also update the relevant refcollections directly, but no big
deal. The Stamp class would then just need to override the iterItems()
classmethod such that it pulled from these refcollections instead of using
a kind query. There would presumably need to also be some kind of
classmethod that returned a set or collection, so that the rest of the
system can still build collections atop stamps. It's just that they'd be
using stamp collections (no pun intended) instead of kind collections. :)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
