Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Fixing "typos" in enums... Date: Mon, 18 Nov 2013 19:38:04 +0100 Lines: 44 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net MRs9tkfcmnZdtN9DfBstcgU447Zuwbs75aLKj4r4d9UJBeKsg= Cancel-Lock: sha1:87+DXR7EIU8pPOANGQ0Xg47XXq0= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 In-Reply-To: X-Antivirus: avast! (VPS 131116-1, 16.11.2013), Outbound message X-Antivirus-Status: Clean Xref: csiph.com comp.lang.java.programmer:26541 On 18.11.2013 18:29, Andreas Leitgeb wrote: > Robert Klemme 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/