Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Fixing "typos" in enums...
Date: Fri, 15 Nov 2013 20:10:42 +0100
Lines: 46
Message-ID: <ben9u0FeoueU1@mid.individual.net>
References: <slrnl8cing.mol.avl@gamma.logic.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net vUXA0B7q02k5l/4l5V3QYwhr1BRhHZyA4/DMn+w4tanJn/JhQ=
Cancel-Lock: sha1:gXye+thDosf9gynoKScDQzFB0xw=
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
In-Reply-To: <slrnl8cing.mol.avl@gamma.logic.tuwien.ac.at>
X-Antivirus: avast! (VPS 131114-1, 14.11.2013), Outbound message
X-Antivirus-Status: Clean
Xref: csiph.com comp.lang.java.programmer:26514

On 15.11.2013 17:25, Andreas Leitgeb wrote:
> Let's assume, some non native English speaker writes up
> a library, that's really useful and gaining broader use.

> Eventually this misspelling goes into an enum constant,
> and by the time the first user reports it, the library
> is already too much in use to lightheartedly apply
> Plan "A" (namely fixing the typo and thereby inducing a
> compatibility issue)
>
> Now, Plan B could be to rename the enum constant, but add
> a public static field by the old bad name (initialized
> with the reference to the spelling-corrected field), to
> alleviate the compatibility issue at least for those who
> merely used the enum's field's name in their code.
>
>   // 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().

Another issue: serialized values.  You might be able to remedy that via 
the deserialization callbacks.  This is at least something that needs to 
be checked.

Even if certain practices are "bad ideas": they are applied nevertheless.

> PPS: a similar problem could arise with misspelled class names,
>    but that's not currently in my focus.

A published API is basically set in stone.  Keeping the wrong value 
might actually be the best option.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/