>Paulm:

>The only time it is less than convenient is when you want to use a
>switch statement.

In Java 5 the new language enum construct can be used directly
with a switch statement. In Java 1.4 with the enum pattern you’d
just include an integer constant as an internal member of your enum
class and switch on ENUM_VALUE.intValue() instead.

>Matt Plumtree:
>Presumably your applyStyle / addStyle methods would use a Set
>internally? Overall this will add overhead relative to the bitwise
>operations, but it must be argued that this is quite
>acceptable overhead.

Similarly, if you really need bitwise operations, each enum
value (either the new Java 5 ones or the old 1.4 enum pattern) can
be given an integer value of your choice to do bitwise operations
with. You’d need to worry about serialization and forward
compatibility, but they are not difficult problems to solve. I’d
probably just use a Set or something similar
though.

I’m not really disagreeing with you. The whole API could do with a thorough going over to use more appropriate idioms. Presumably your applyStyle / addStyle methods would use a Set internally? Overall this will add overhead relative to the bitwise operations, but it must be argued that this is quite acceptable overhead. The resultant API will be clearer and, as you point out in the original posting, less fragile.

The usual OOP way to avoid the switch would be to have an actual method of FontStyle to do the work. Then, the style set would be iterated over, getting each one to apply its feature. I’m not sure this would be entirely appropriate for this example, but it would depend on just how font styles were implemented.

I suppose additional styles you could add would be things like underline, strike through, superscript, subscript and so on, much as you might see in a word processor’s font characteristics dialog.

I think it just has to be accepted that there are many parts of the Java API that are immature. I know you have argued before for a proper cleanup, but Sun’s preference for compatibility generally win out.

Pascal had enumerated types whose values were disjoint from the integers over twenty years ago.

Joshua Bloch clearly defined the technique as item 21 of Effective Java. The only time it is less than convenient is when you want to use a switch statement. Even then you can have the object generate/return a unique integer.

Using bitwise constants and bitwise arithmetic to pick font styles is pretty old, C-style thinking. It’s a neat hack; but it’s not really necessary here. The right way to solve this problem is to replace setStyle with applyStyle or addStyle or some such method. You may want a removeStyle method too. An added advantage of this is you’re no longer limited to a maximum of 8 or 32 constant values. You can define as many as you need.

You would need to have a FontStyle.BOLDITALIC. Or is that FontStyle.ITALICBOLD? Or FontStyle.BOLD_ITALIC? Or a FontStyle.and(FontStyle other) method? Or something.

This is a slight disadvantage of using true types for combinations of values, that using ints doesn’t have.

Pre-canned combinations are going to be more efficient than using a combining method, since they will be created once then assigned straight into classes as they are loaded, but their number increases exponentially as more mutually inclusive options are added. Consider all the constants to enter (and their names) if you had 8 options that could be combined in any way.

You may also need to have big switch statements in the implementation of Font, to deal with each combination, possibly just to turn them back into a bitfield. Alternatively you could embiggen FontStyle to include isBold() and isItalic() methods. This would require initializers for each style, probably bringing us back to bitfields again. However, at least they would be localized to the FontStyle code. ]]> http://cafe.elharo.com/blogroll/arguments/comment-page-1/#comment-78 Elliotte Rusty Harold Fri, 06 Jan 2006 22:37:24 +0000 http://minicafe.elharo.com/wordpress/java/arguments/#comment-78 <h3>Part 2</h3> I am working on a second half to this article that will consider: ClassLoader issues Serialization Enums Part 2

I am working on a second half to this article that will consider:

ClassLoader issues
Serialization
Enums

Also, see Josh Bloch’s Effective Java, where he details a pre-5 enumeration idiom. I also cover this in Thinking in Java.