> [CB] That's actually why I implemented equals that way, so I would to be > able to pass in a String and have it compare to the actual enum's value as > well as the enum itself, but feel free to change the equals implementation > I > guess it does violate the description. >
ah I see, did not know you want to pass in Strings like that > And why not use simple 'int' values using switch/case ? better performance > than an ArrayList full of Strings.. and if I would use Strings I would > prefer a HashSet or something, that way the lookup is in constant time, > not O(n). > > [CB] Because I want the option of using Strings, I don't want to be > limited > to only integers. And trust me, I'm sure you'll have bigger performance > concerns in your system than worry about a few strings in an array list. > If > you want to change it to a HashSet feel free, it doesn't affect the way it > works. The way its currently implemented now you can use more than one > type > and I prefer the flexibility. > I guess it makes sense in some cases to use Strings .. I never needed it so I prefer primitives as the value type what concerns the fromString() or fromInt(): never used them directly, all the logic I ever needed from enums were hidden in their implementation -- Wouter ps: if you intended to accept Strings for an equality test I guess your implementation was right not to call .super.equals() (except for the contract) I will leave it up to you to apply any changes ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Andromda-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-devel
