lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tatu Saloranta <t...@hypermall.net>
Subject Re: Field.java -> STORED, NOT_STORED, etc...
Date Sun, 11 Jul 2004 17:45:56 GMT
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


Mime
View raw message