David E. Wheeler wrote on 4/16/11 11:05 AM: > On Apr 15, 2011, at 8:27 PM, Peter Karman wrote: > >> This, I'm not so sure about. At least, it should be configurable, with a >> 'strict' flag or similar, which if enabled, would throw errors if 'foo' was >> not a defined field. Otherwise, depending on the user, we're in the realm >> of silent failure rather than gracious host. > > That just trades one level of complexity (heed_colons) for another (strict).
/me nods > >> Do we even have a feature for public/private fields atm? > > Yes, Marvin says it will search only those you list in the constructor, > unless you have heed_colons on and someone specifies a field not listed. > ah. thanks for clarifying. >> I think the focus on reliable, flexible *Query classes has been a good >> design choice to date, because it means that it is quite straightforward to >> roll your own query parser (as I have done), entirely suited to your >> application's needs, sidestepping the Lucy QueryParser altogether. That's >> good library design, imo. > > So maybe there isn't a need for a strict parser? agreed. > >> I agree that Lucy QueryParser should get simpler over time, by losing >> features, but not convinced that the behavior you're proposing actually >> does that. I'm happy to be convinced though. > > Given the audience it currently targets (web search box users), I think it > makes sense to try to adhere to the principal of least astonishment. > that was convincing. :) +1 -- Peter Karman . http://peknet.com/ . [email protected]
