Maybe we should have a standard enum template that defines everything that belongs in the enum class. It would be easiest if enums could inherit from each other, or if they weren't final classes, but that doesn't work. I am thinking of some conversion from and to the simple type underlaying it, but that doesn't work for the binary formats. Maybe the better way is to have a conversion class that takes the various enums and converts them from/to the various simple types.
On Sun, Jul 10, 2016 at 2:51 AM, <bugzi...@apache.org> wrote: > https://bz.apache.org/bugzilla/show_bug.cgi?id=59836 > > Bug ID: 59836 > Summary: Replace primitives with enums > Product: POI > Version: 3.15-dev > Hardware: PC > OS: Linux > Status: NEW > Severity: enhancement > Priority: P2 > Component: SS Common > Assignee: dev@poi.apache.org > Reporter: one...@apache.org > > This is a aggregate bug for recent changes in classes from using short or > int > to using enums with codes. > > Benefits: > * self-explanatory usage rather than needing to list the valid constants > in the > javadocs > * easier to distinguish arguments in function signatures (not just a 5 > ints) > * clearer error messages, no functions needed to convert code to string > * free range checking (less boiler plate code that does the same) > * type safety > > Drawbacks: > * some permgen overhead > * type checking execution overhead > > Overall, this seems like a good thing. > > In effort to maintain backwards compatibility, the following is suggested: > > If there is currently > int getSomething(); > void setSomething(int); > > Then we should add > enum getSomethingEnum(); > void setSomething(Enum); > > And deprecate > void setSomething(int); > int getSomething(); > > It's a bit tricky handling getSomething/getSomethingEnum while maintaining > backwards compatibility because at some point the signature will abruptly > change. Both getters should be offered for a while with a note encouraging > users to use the constants or enums rather than using literal values. This > is > good coding practice anyway to not hard-code literal values, but is > especially > important with regard to backwards compatibility here. > > At least 2 releases later, but not later than POI 4.0: > Delete void setSomething(int); > Delete int getSomething(); > Rename enum getSomethingEnum(); to enum getSomething(); > > In the end, we will have > enum getSomething(); > void setSomething(enum); > as the only two methods. > > -- > You are receiving this mail because: > You are the assignee for the bug. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
