[
https://issues.apache.org/jira/browse/LUCENE-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768215#action_12768215
]
DM Smith edited comment on LUCENE-1998 at 10/21/09 2:22 PM:
------------------------------------------------------------
bq. I only added the license header back in the Version class. It must be there.
Sorry about wacking the license on Version. It must have been an accident. I
know it needs to be there.
bq.Some fine tuning: You defined package protected abstract methods, but made
them public in the enum constant. Changed to all-public. This was also a
backwards-break in contrib/queryParser.
Thanks. Inadvertently, I was following the pattern for an Interface, where
scoping does not matter.
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.
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.
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?
was (Author: dmsmith):
.bq I only added the license header back in the Version class. It must be
there.
Sorry about wacking the license on Version. It must have been an accident. I
know it needs to be there.
.bq Some fine tuning: You defined package protected abstract methods, but made
them public in the enum constant. Changed to all-public. This was also a
backwards-break in contrib/queryParser.
Thanks. Inadvertently, I was following the pattern for an Interface, where
scoping does not matter.
.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.
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.
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?
> 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
