Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 33AB8648E for ; Wed, 6 Jul 2011 05:34:34 +0000 (UTC) Received: (qmail 24764 invoked by uid 500); 6 Jul 2011 05:34:32 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 23696 invoked by uid 500); 6 Jul 2011 05:34:20 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 23678 invoked by uid 99); 6 Jul 2011 05:34:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jul 2011 05:34:17 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gento0nz@gmail.com designates 209.85.216.169 as permitted sender) Received: from [209.85.216.169] (HELO mail-qy0-f169.google.com) (209.85.216.169) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jul 2011 05:34:11 +0000 Received: by qyk32 with SMTP id 32so2259785qyk.14 for ; Tue, 05 Jul 2011 22:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0nRsTyFxN3Z8wO/mSYOmDHOsdWtzcs8e0cqiBIyS7RE=; b=es8gvo+P1iRN2ghNjvYa4TrJNGrT4DdezVvHcygxog2qL3ytqFNS37odnPz3BXhZZK lJACzD1naHTlqkRCcVM32axqpc6o9YN9d10FhE9WUOc5L5OZlD1FN/N+z2DqVe7do3ui U8LXD2MAh0TmQOtYSbSo305tdolTLuDfceUBc= MIME-Version: 1.0 Received: by 10.229.135.12 with SMTP id l12mr6190934qct.53.1309930430452; Tue, 05 Jul 2011 22:33:50 -0700 (PDT) Received: by 10.229.220.66 with HTTP; Tue, 5 Jul 2011 22:33:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Jul 2011 17:33:50 +1200 Message-ID: Subject: Re: QueryParser names From: Chris Male To: dev@lucene.apache.org Content-Type: multipart/alternative; boundary=00248c7117c7fcd34404a75ff1ca --00248c7117c7fcd34404a75ff1ca Content-Type: text/plain; charset=ISO-8859-1 Hi Adriano, On Wed, Jul 6, 2011 at 5:26 PM, Adriano Crestani 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 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 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-unsubscribe@lucene.apache.org >> For additional commands, e-mail: dev-help@lucene.apache.org >> >> > -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl --00248c7117c7fcd34404a75ff1ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adriano,

On Wed, Jul 6, 2011 at 5:26 P= M, Adriano Crestani <adrianocrestani@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, sin= ce 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 goin= g for. =A0The packages may very well be changed but I'm really open for= suggestions on the issue.
=A0

StandardQueryParser and core.QueryParser have (or should hav= e) 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 exactl= y what they do. Suggestions?

Could we not change StandardQueryPar= ser to FlexibleQueryParser? Standard gives the wrong impression I feel. =A0= We have the ExtendableQueryParser which supports Extensions so maybe Flexib= leQueryParser suggests its flexible API?
=A0

I like the idea of creating a simple QueryParser interf= ace as Robert mentioned. Actually, we have something similar: SyntaxParser.= Although it's not compatible with the interface Robert mentioned.

Yeah the SyntaxParser-esque interfac= e would work. =A0It could certainly help down the line where maybe we want = randomized QueryParser implementation selection or something, or modules wh= ich can handle QPs plugged in.
=A0


On Wed, Jul 6, 2011 at 1:19 AM, Robert Muir = <rcmuir@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 <gento0nz@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 coul= d
> probably be clearer. =A0For example, we currently have two parsers cal= led
> QueryParser. =A0Given that the core QueryParser is no longer going to = be in
> core, I think it could do with a name that more accurately describes i= ts
> 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 (queryparse= r
> contrib)
> Cheers
> Chris
> --
> Chris Male | Software Developer | JTeam BV.| www.jteam.nl
>

---------------------------------------------------------------= ------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org





--
Chris Male | Software D= eveloper | JTeam BV.| www.jteam.nl
--00248c7117c7fcd34404a75ff1ca--