lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1998) Use Java 5 enums
Date Wed, 21 Oct 2009 13:51:59 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768242#action_12768242
] 

Uwe Schindler commented on LUCENE-1998:
---------------------------------------

(it's "bq." not ".bq" :-) )

{quote}
bq. So it works, but not with switch statements.
IMHO: Having a switch statement (or cascading if-then-else) over the collection of values
is generally indicative of a bad design (or an opportunity for an improved design  By adding
methods to each enum that return literals, we can eliminate this and at the same time, improve
performance.
{quote}

You are right, my problem was more for client code of Lucene that may for example have a switch
statement on Field.Index (e.g. Solr) to control some further indexing steps. If we rename
the constant, the switch statement would not work (it would work in already compiled code),
but not if the code is recompiled against the modified version. That was my problem. In 3.0
this will not happen as there are no deprec enum constants, but maybe later. In this case,
a CHANGES.txt entry should be added.

bq. There is another tuning opportunity, which I didn't take. We are marshaling out the flags
from the enums into member variables. I'm not sure how efficient the storage of a boolean
vs an enum is. If it is a wash, then having an enum value as replacement would be a good thing.
It sould clearly document what controls the flag.

This is currently not possibible because of backwards compatibility, because the fields are
protected and not deprecated in 2.9. I think with your change we are fine.

bq. The only complication would be the set/get for some of the flags. (E.g. AbstractField.setOmitNorms.)
What's with that? Are the enum values merely a hint??? Does it make sense to allow omitNorms
to be changed after an AbstractField is being used?

It is perfectly legal to change these constants after creating the field, so the setters must
be there.

> Use Java 5 enums
> ----------------
>
>                 Key: LUCENE-1998
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1998
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 3.0
>            Reporter: DM Smith
>            Assignee: Uwe Schindler
>            Priority: Minor
>             Fix For: 3.0
>
>         Attachments: LUCENE-1998_enum.patch, LUCENE-1998_enum.patch, LUCENE-1998_enum.patch,
LUCENE-1998_enum.patch
>
>
> Replace the use of o.a.l.util.Parameter with Java 5 enums, deprecating Parameter.
> Replace other custom enum patterns with Java 5 enums.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message