On Thu, Apr 28, 2011 at 7:31 PM, Alex Mizrahi <killerst...@newmail.ru>wrote:
> > Why? I am by no means an expert and never looked thoroughly the code, > > but ,abstractly speaking, doesnt it boil down to just creating > > more indexes automatically at class definition time? > > Code assumes that there is only one index it needs to update at time, so it > needs to be revised to handle many of them. > Nothing particularly hard, but it requires some code rewriting and thus > > While another alternative is pretty much trivial. > > > Independently of the whole subject, I think this should be done anyway, > > and it can be an optional param with a default for old behaviour for > those > > who want the whole pie. > > I think many people subtypep the results of get-instance family funcs > > early in their projects. > > I don't think that 'old behaviour' was intentional, people should not > depend > on query for one sub-class returning instances of another sub-class. > And it is trivial to fix it -- just pass super-class instead of sub-class > to > this function if you want all instances. > > So I think get-instances-by-... should unconditionally do the filtering. You are right then. > While map-inverted-index probably shouldn't do the filtering. I consider it > a lower-level API which works with index directly, without a promise to > return instances of certain class. > And also implementing it at that level is somewhat harder. > > Totally agree with that. From the index point of view, class hierarchy relationships are irrelevant and even non existent, since at that level the only distinguishable relationship is the key-value one. It would be wrong to inject such semantics at that level. > > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel >
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
