Re: Fixing "typos" in enums...
On 18.11.2013 18:29, Andreas Leitgeb wrote:
Robert Klemme <shortcutter@googlemail.com> wrote:
// public enum Foo { FURST, SECOND }
public enum Foo { FIRST, SECOND; public static final FURST = FIRST; }
Any user having done a switch over that enum will still
need to modify his code. Ditto anyone doing string comparisons
on foo.name(), but that is most probably a bad idea, anyway.
Not at all: a String could be read from some configuration file or
database and then the corresponding enum value searched via valueOf() or
values().
Fair enough. De-serialization from some persistent storage sure is
a legit task, that would suffer from such an API-change.
Basic Object-(de)serialization would be less of a problem, as that is
already specified as unsuitable for long-time storage.
Well, but it *can* be used for that purpose which means it *will* be.
And telling them "it's your fault" is often not a good option as there
can be numerous ugly ways that can backfire...
A published API is basically set in stone. Keeping the wrong value
might actually be the best option.
I just don't yet want to accept it, even though I can't refute it. ;-)
:-) At the university we had a lecture about exactly this kind of
problem and other issues specific to API changes in OO languages.
Unfortunately I neither remember the professor's nor the lecture's name
to dig up some pointers. What I took away was that sentence ("...set in
stone") and that there is quite a number of surprising and subtle ways
failure can be caused by API changes. That had two effects: it made me
think thrice whenever I am tempted to change an API; and I try to give
extra thought whenever I am designing an API (not only the public ones
as often all of a sudden what has been private becomes public).
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/