#14 Leaf-level merge of collections
When you do a query, you get back instances of what you
asked for. For example, if you do a ReaderQuery, you
get back a ReaderCollection. Now if Mary and Sue are
Readers, and Eric and Steve are Resources (in TaskHeap
ResourceStruct extends ReaderStruct), then a general
ReaderQuery would return.
Mary
Sue
Eric
Steve
Whereas a ResourceQuery would return
Eric
Steve
Now remember: Eric and Steve are Readers in the first
list. They are Reader objects. They are not Resource
objects polymorphised into the same list, they are
Readers. It is somewhat tempting to think about having
a polymorphic list of Readers, where some of the
elements are in fact Resources, but
just because ResourceStruct extends ReaderStruct,
that doesn't mean that Resource extends Reader.
It doesn't.
It doesn't for security and efficiency and other
similar reasons. You can have a polymorphic list, but
it will be of SandMessage instances (or a similar
root), not polymorphic Readers.
That said, a polymorphic list is still useful.
Writing a polymorphic list is sort of a hassle, and
the code actually has all the inheritence info in data
structures. So given adequate query methods (or by
basing all processing off the resolveXYZReference
methods which take an IDLookup), it should be possible
to create the leaf node list automagically.
It is probably not a good idea to stuff the leaf node
name in the actual instance. If somebody who knows
about Readers is not authorized to know about
Resources, then this gets complicated. Don't do this.
A method can trap the exceptions thrown due to an
illegal access of a leafier class, and react
appropriately so that leaf nodes are merged in subject
to authorization processing.
