--- Brent Pinkney brent.pinkney@aircom.co.za wrote:
The way I envision this working from a user
perspective is, the user "Reads" a
collection on one index (and thus obtains a
Reader), then can "intersect:" that
Reader with another Reader to build yet a third
Reader, which can be further
intersected with other Readers as necessary.
I think we need to concentrate on the elegance of the programming api: normal AND and ORs.
Well yes, of course it would be great to have that.. Are you serious? Not only is that more familiar and elegant to programmers, it doesn't waste cycles like my approach which performs but a single intersection for each "condition".
I like the ambition, just a bit short on clarity about,
The idea is that each send of #read:at:, #and:from:to:, #or:at: to the reader contucts a tree of clauses. These clauses are then used to determine the intersection and union of oids.
particularly that last sentence. If you are able to do that, I am all for it.
No work needed to add an arbitrary-complex tree to the client server protocol beyond just specifying the new class in the #protocol..
I have some experience from Lava with conjuntive and dijunctive clauses but we would need to find a way to express precedence or the and: or: clauses.
Don't forget the joins.. ;)
- Chris