> 2. if we go for native UML enumerations we should update the profile to be
> able to use our stereotypes on those elements too (set base element to
> DataType instead of Classifier)
>
> [CB] What you mean, don't understand what you're saying here.
>
currently it is impossible to add our stereotypes to enumeration model
elements in MD (try it, you'll see what I mean), enumeration is a DataType
so changing a stereotype's base class to DataType would do the trick
> 3. this brings us to something which was already discussed some time ago:
> why not fork the notion of 'persisted' from the entities ? right now the
> entities we model are implicitely persisted, but do we really want that ?
>
> [CB] We could do this however we should probably wait until after 3.0
> since
> it's a major change (I thought we talked about this already?)
>
yes I know, but I wanted to bring this up again anyway
> 4. if we use enumerations, how should we stereotype them ? should we add a
> stereotype 'Persisted' or something ?
>
> [CB] Only persisted ones, non-persist ones are not gonna use the
> <<Persistant>> stereotype.
>
please :-) since we're not going to go for native enum support in XMI
we'll postpone this issue until we actually need it, nevermind
> 5. I would like to update the enumeration support from the Java cartridge,
> to be honest I don't really understand how the current template implements
> an enumeration .. I think the implementation is very weird, it's using an
> ArrayList and Strings for some reason, I would like to improve this by
> using integers and by properly implementing the equals/hashCode methods,
> ideas ?
>
> [CB] It's actually not very weird at all, they are type safe enums and I'm
> using them in several projects, take a look at the test model in the java
> cartridge to see how to model them. The array list is there to keep track
> of the valid values that can be used to create the enum when using
> fromString, fromInteger, etc (depending on what the type is). (by the
> way,
> enumerations are Strings a lot of the time). Please don't change the
> implementation it works well.
>
you wrote that template ? well, I personally don't like the fact that you
compare enum types for equality using .toString() on the object like this:
public boolean equals(Object object)
{
return object != null &&
object.toString().equals(
this.toString());
}
suppose the argument object is a String instance and NOT an enum of this
type (or even worse: an enum of another type), in this case your
implementation might still return true, this violates the .equals()
contract :
"The equals method for class Object implements the most discriminating
possible equivalence relation on objects; that is, for any non-null
reference values x and y, this method returns true if and only if x and y
refer to the same object (x == y has the value true)."
When overriding you should normally always call super (Liskov).
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).
can you let me know ? thanks.
-- Wouter
okay, I will use my own template
> You can however add persistent enumeration support to the Spring
> cartridge,
> there's native support for the in hibernate, and there's a template that
> someone actually contributed a while back I think it might be in the
> sourceforge patch area.
>
> -- Wouter
>
>
>
> -------------------------------------------------------
> 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
>
>
-------------------------------------------------------
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
