Please rethink extended enums inclusion
Jose Antonio Illescas Del Olmo
jantonio.illescas at rbcdexia-is.es
Fri Oct 7 06:18:35 PDT 2011
On 07/10/2011 14:32, Henri Gerrits wrote:
> Hi Jose Antonio,
> I have some issues with your proposal:
> 1. Inserting a superclass with new methods might break many existing enums
Why? I decide when extends from custom abstract enum (checking that
works fine) other enums (extends from "standard" enum) and works as ever.
> 2. Why do you need a code field? The name() method already returns a
> unique value. The static valueOf() method can then be used instead of
> your fromCode() method. I don't think caching makes much sense with
> enums, since the number of possible values are usually fairly small
We have many communications with other finantial entities that use
"standard protocols" with custom codes, while our application use
descriptive enum names (on enums maps this relation between enums and
codes).
Our enums can parse from "standard codes" to enums and viceversa.
> 3. Although the in(T...) method does look nice at the call site, I
> think it has nothing to do with the enum; it belongs to a collection
> class (as "contains()", which admittedly means you need to have a
> collection instance at the call site)
:-(
> 4. You could also implement the in(T...) method by "mixing in"
> a (generic) interface using an extension method
>
Sure, but I like if this method exist for any enum...
> Best regards,
Thank you, Henri
> Henri
>
> *From:* Jose Antonio Illescas Del Olmo
> <jantonio.illescas at rbcdexia-is.es>
> *To:* coin-dev at openjdk.java.net
> *Sent:* Friday, October 7, 2011 7:34 AM
> *Subject:* Please rethink extended enums inclusion
>
> Now we have hundred of enums on our project (finantial application
> with
> 120.000 lines) an repeat same code on any enum... (*mark as red*)
>
>
> * Map our enums with old legacy system codes:
>
> public enum Type {
>
> ONE("01), TWO("03"), THREE("03"), ...;
>
> private Type(String code) {
> setCode(code);
> }
>
> * private String code;
> *
> * public String code() {
> return code;
> }
>
> public void setCode(String code) {
> this.code = code;
> }
>
> ** public static Type fromCode(String code) {
> if (code == null) return null;
> for(Type type: values()) {
> if (type.code.equals(code) return type;
> }
> return null;
> }
>
> ** public boolean in(Type... types) { // IMO all enums must
> have
> this method
> if (types == null) return false;
> for(Type type: types) {
> if (this == type) return true;
> }
> return false;
> }
> *
> Or with cache to avoid for iteration on fromCode(String) method =>
> more
> code is necesary
>
> public enum Type {
>
> ONE("01), TWO("03"), THREE("03"), ...;
>
> private Type(String code) {
> setCode(code);
> }
>
> * private String code;
>
> ** private static Map<String, Type> cache= new
> HashMap<String,Type>();
>
> static {
> for(Type type: Type.values()) {
> cache.put(type.code(), type);
> }
> }
> *
> * public String code() {
> return code;
> }
>
> public void setCode(String code) {
> this.code = code;
> }
>
> ** public static Type fromCode(String code) {
> return cache.get(code);
> }
>
> ** public boolean in(Type... types) { // IMO all enums must
> have
> this method
> if (types == null) return false;
> for(Type type: types) {
> if (this == type) return true;
> }
> return false;
> }*
>
> /Abstract enums with Generic support reduce dramatically the code of
> enums, see next code that use abstract enums:
> /
> *public enum Type extends MyAbstractEnum<String> {
>
> ONE("01), TWO("03"), THREE("03"), ...;
>
> private Type(String code) {
> super(code);
> }
> }*
>
>
>
>
More information about the coin-dev
mailing list