Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@www.apache.org Received: (qmail 35533 invoked from network); 11 Jul 2004 17:46:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 11 Jul 2004 17:46:19 -0000 Received: (qmail 88845 invoked by uid 500); 11 Jul 2004 17:46:14 -0000 Delivered-To: apmail-jakarta-lucene-user-archive@jakarta.apache.org Received: (qmail 88818 invoked by uid 500); 11 Jul 2004 17:46:13 -0000 Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Users List" Reply-To: "Lucene Users List" Delivered-To: mailing list lucene-user@jakarta.apache.org Received: (qmail 88803 invoked by uid 99); 11 Jul 2004 17:46:13 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [216.241.36.13] (HELO mz2.forethought.net) (216.241.36.13) by apache.org (qpsmtpd/0.27.1) with ESMTP; Sun, 11 Jul 2004 10:46:10 -0700 Received: from j72.denver.dsl.forethought.net ([216.241.38.72]) by mz2.forethought.net with esmtp (Exim 4.30) id 1BjiOm-0005bO-Nc for lucene-user@jakarta.apache.org; Sun, 11 Jul 2004 11:46:04 -0600 From: Tatu Saloranta Reply-To: tatu@hypermall.net Organization: Linux-users missalie To: "Lucene Users List" Subject: Re: Field.java -> STORED, NOT_STORED, etc... Date: Sun, 11 Jul 2004 11:45:56 -0600 User-Agent: KMail/1.5 References: <40F102A6.4090302@newsmonster.org> <40F15E56.3060808@apache.org> <40F164BB.6070405@apache.org> In-Reply-To: <40F164BB.6070405@apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200407111145.56576.tatu@hypermall.net> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Sunday 11 July 2004 10:03, Doug Cutting wrote: > Doug Cutting wrote: > > The calls would look like: > > > > new Field("name", "value", Stored.YES, Indexed.NO, Tokenized.YES); > > . > Actually, while we're at it, Indexed and Tokenized are confounded. A > single entry would be better, something like: ... > then calls would look like just: > > new Field("name", "value", Store.YES, Index.TOKENIZED); ... > and adding a boolean clause would look like: > > booleanQuery.add(new TermQuery(...), Occur.MUST); > > Then we can deprecate the old methods. > > Comments? I was about to suggest this, instead of int/boolean constants, since it is a "recommended good practice", and allows better type safety (until JDK 1.5's real enums at least). I would prefer this over un-typesafe consts; although even just defining and using simple consts in itself would be an improvement over existing situation. Another possibility (or maybe complementary approach) would be to just completely do away with constructor access; make the constructors private or protected, and only allow factory methods to be used externally. This would have the benefit of even better readability: minimum number of arguments (method name would replace one or two args) and full type checking. Plus it'd be easier to modify implementations should that become necessary. Factory methods are especially useful for classes like Field, that are not designed to be sub-classed. -+ Tatu +- --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-user-help@jakarta.apache.org