Hi Adriano, On Wed, Jul 6, 2011 at 5:26 PM, Adriano Crestani <adrianocrest...@gmail.com>wrote:
> Are there any plans to change the package name as well? If not , I don't > see any reason to change surround.QueryParser to SurroundQueryParser, since > all "QueryParser" classes are in different packages. The only advantage is > less confusion for the user. Less confusion for the user is exactly what we are going for. The packages may very well be changed but I'm really open for suggestions on the issue. > > StandardQueryParser and core.QueryParser have (or should have) the same > behavior. The difference is that StandardQueryParser has a more flexible > API. So I am not sure how you would rename them to reflect exactly what they > do. Suggestions? > Could we not change StandardQueryParser to FlexibleQueryParser? Standard gives the wrong impression I feel. We have the ExtendableQueryParser which supports Extensions so maybe FlexibleQueryParser suggests its flexible API? > > I like the idea of creating a simple QueryParser interface as Robert > mentioned. Actually, we have something similar: SyntaxParser. Although it's > not compatible with the interface Robert mentioned. > Yeah the SyntaxParser-esque interface would work. It could certainly help down the line where maybe we want randomized QueryParser implementation selection or something, or modules which can handle QPs plugged in. > > > On Wed, Jul 6, 2011 at 1:19 AM, Robert Muir <rcm...@gmail.com> wrote: > >> Hi Chris, >> >> I hate to add confusion to this, but I wonder, do we have an idea how >> many modules will need to interact with a queryparser? >> If so, it might be worth making a simple abstract or even interface >> queryparser in core with something like Query parse(String text) >> throws ParseException >> >> This could be overkill, but it would allow modules that need to use >> this stuff to depend upon the interface, not the implementation... >> again feel free to ignore me, but this is how we pulled this off with >> Analyzer. >> >> Otherwise, another idea you could consider is naming the surround one >> SurroundQueryParser? >> >> On Wed, Jul 6, 2011 at 1:00 AM, Chris Male <gento...@gmail.com> wrote: >> > Hi, >> > I'm in the process of consolidating the various QueryParsers into a >> single >> > queryparser module and Ryan reminded me that the names of the QPs could >> > probably be clearer. For example, we currently have two parsers called >> > QueryParser. Given that the core QueryParser is no longer going to be >> in >> > core, I think it could do with a name that more accurately describes its >> > purpose. >> > Does anybody have any thoughts on how to name the following parsers: >> > org.apache.lucene.queryParser.QueryParser (lucene core) >> > org.apache.lucene.queryParser.surround.parser.QueryParser (queryparser >> > contrib) >> > org.apache.lucene.queryParser.standard.StandardQueryParser (queryparser >> > contrib) >> > Cheers >> > Chris >> > -- >> > Chris Male | Software Developer | JTeam BV.| www.jteam.nl >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl
