[ 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