[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
