Marvin Humphrey wrote on 3/22/10 1:10 AM: > > We should zap my TODO test. >
ok. >> I think simpler is better here: if you want order to not matter, then OR >> together the various orders you might be interested in. In fact, I may offer >> that as an option in the Search::Query::Parser, which could then do the ORing >> programmatically. Likewise, if we choose to support the "a b"~N syntax in >> the KS >> QueryParser, could do something similar. > > I'd rather shunt people who need more than the basic syntax of the core > QueryParser towards yours than try to imitate it. :) heh. fair enough. :) I've added prelim support to Search::Query::Dialect::KSx and Search::Query::Parser in svn. I'm not sure yet how to offer the optional "ignore order" feature. Maybe a 'ignore_order_in_proximity' flag. I'll have to think about if that should also affect serialization. It would need to be in Dialect::KSx, since the other dialects I'm currently supporting do not have that kind of feature. > >>> Superficial stylistic suggestion: I might propose "proximity" (or >>> "nearness", >>> but "proximity" is better) instead of "near" for the name of that parameter. >>> Or alternately, "slop", but I understand why you went with nearness instead. >> >> I like 'proximity' for consistency's sake. And yes, 'near' is not quite >> right. >> How about 'within'? Or 'vicinity'? > > Those all seem fine to me. I'd cast my vote for "proximity" just because you > chose to call the class "ProximityQuery" and an exact name match seems easiest > to remember, but "within" is a little easier to spell and just has a slightly > more "natural language" linguistic emphasis as opposed to more traditional > "noun = value" naming style. I like 'within' -- easy (enough) to remember and type. changes pushed in r5942. thanks for the thorough review, Marvin. -- Peter Karman . http://peknet.com/ . [email protected]
