Guava: CaseFormat is not extensible

[philgebhardt]

Because CaseFormat is an enum, one cannot implement their own case format. This would be useful for scenarios such as the one mentioned here https://github.com/google/guava/issues/699.

It seems to me, a straightforward change to support this would be to turn CaseFormat into an abstract class and make all of the implementations (e.g. CaseFormat.UPPER_UNDERSCORE) static variables, pointing to instances of implementing classes (e.g. UpperUnderscoreCaseFormat).

Then, anyone could add their own CaseFormat implementations (like TitleCaseFormat) that suit their use case.

Of course, this would be considered a breaking change to anyone relying on this class being an enum (like in the case of iterating over all values using CaseFormat.values())

[jbduncan]

Or, even better, a la Effective Java, make CaseFormat implement an interface that has all the necessary methods that a case formatting "thing" would need. Then other non-Guava case formatting classes could implement an interoperable interface and be able to extend other, entirely separate abstract classes if needed.

But again, unless we can find a good name for the interface, it would be a breaking change as CaseFormat itself would have to become the interface, and the existing CaseFormat enum would have to be renamed e.g. StandardCaseFormat. (And by extension CaseFormat would no longer be an enum.)

Basically, if this issue is accepted and regardless of whether it would mean a breaking change or not, we'd have an advantageous situation similar to the existing Charset interface and being able to use either the Java standard library's StandardCharset or Guava's Charsets or a different implementation.

[cgdecker]

CaseFormat is a bit of a weird class that was only really intended to convert between different case formats used in Java source code.

Changing it to implement an interface... doesn't really look like an approach that would work, at least not well, because CaseFormat relies on package-private methods implemented by the constants, which would have to be made public to make it an interface, which would add methods to the API that users shouldn't actually use. I don't think there would be enough value in doing this to justify doing that.

[cgdecker]

Note, years later: I was apparently misremembering about CaseFormat only being usable for Java source code identifier formats. Though I'm still of the opinion that we probably don't want to try to make it extensible.