2011/4/29 16:28 -0700, mike.duigou@oracle.com:
Hi Mark;
I'm still not on your wavelength on this issue. For two reasons:
- Collections, Arrays, Channels, Objects aren't typically used for holding constants. They are either factories or collections of static utility methods. Only Collections actually defines any constants and those probably should have been put on the respective interfaces.
The constants in the Collections class weren't put into the related interfaces because that would have polluted any implementing class or subinterface with that constant name. Constants in interfaces are almost always a bad idea.
The closest example seems to be PosixFilePermission (an enum) vs. PosixFilePermissions (static utility methods). The one difference is that PosixFilePermission is exhaustive, no other permissions are possible, vs the standard charsets where they represent only a subset of the available charsets. AFAIK even ME distributions have more than just the standard charsets.
For the standard charsets we've got no methods, only constants. Is Charsets preferred only because we want to avoid putting these constants on Charset itself for the previously cited performance reasons?
To be clear, I'm not objecting to the prefix "Standard" -- I'm just arguing in favor of the suffix "s".
- The standard charset constants do seem like an enum. The enumeration they belong to is easily named and part of the platform specification.
Conceptually, I agree.
Putting these definitions all into one class makes membership obvious--the standard charsets are the ones in this class.
Yep.
Charsets not defined in this class are not standard and thus not guaranteed to be available. (which is an interesting point, though the standard charsets are now visible in the platform we still don't provide a way to test whether a given charset is a member of the set of standard charsets).
That is an omission, but I wonder if anyone cares? (A possible fix would be to define StandardCharsets.ALL as a set containing all the singletons defined in the class.)
Barring history and implementation details I don't see why we wouldn't be defining these constants as an enum implementing Charset the same way as we've defined the jsr203 Standard* enums. The enum members would have more implementation than the jsr203 Standard* enums, ie. more than identity but almost all of that is constant data itself.
That would require Charset to have been defined as an interface, which in turn would've added substantial complexity to the original design. At any rate, it's water under the bridge at this point.
What makes these constants *not* an enumeration?
If I have the enum type enum Foo { BAR, BAZ } then the following assignment works: Foo x = Foo.BAR; A statement of that form does not work with your StandardCharset class: StandardCharset x = StandardCharset.US_ASCII; That's because StandardCharset is a final class and it does not extend Charset, nor any other class or interface except Object. It's just a holder for a bunch of convenient constants, like java.util.Arrays and j.u.Collections, etc. The only difference is that it defines some static constant values but no static methods. In short, the hallmark of an enum type is that its members all have the same type, and that type is the enum type itself. This is true whether you use the fancy enum construct from Java 5 or the older hand-coded enum pattern. Your StandardCharset class is not an enum type. In order to fix this you could change StandardCharset to extend Charset, but then you'd have to jump through some hoops to make the standard charset implementation classes extend StandardCharset rather than plain Charset, and you'd have to be careful not to allow anyone to extend StandardCharset. Offhand this seems to require moving the standard charset implementations into the java.nio.charset package itself. That's an awful lot of effort for just a handful of constants.
I'm not trying to be difficult on this, honestly.
I understand. Me neither. - Mark