On 5/18/07, Larry Cable <lcable_at_bea.com> wrote:
>
> although I think it is stretching/breaking the meaning of an enumeration
> and introducing these constants as enums may make their usage harder rather
> than simpler actually we could ala:
>
> public enum Language {
> EN("en"),
> // ...
> FR("fr");
>
> private Language(final String l) { language = l;}
>
> public boolean equals(Object o) { return language.equals(o); }
>
> public int hashCode() { return language.hashCode(); }
>
> public String toString() { return language.toString(); }
>
> private final String language;
> }
Yea this is something I do often in non-framework (client) code. It is a
neat hack, but it wont work for us because you cant invoke a dynamic method
on an annotation:
@Language(Languages.EN.toString()) //wont compile
> the problem I see with that is that if we did not provide a rich enough
> set of values in the enum a developer would
> be forced to extend that set by inheritance
Yea, and this doesnt work with enums too (final). =(
There is always a need to extend this sort of stuff (klingon anyone?)
... so maybe just simple string constants will be enough
Agreed. Interning common-use strings into a class of constants ought to be a
good start if not an ideal finish.
Dhanji.