Home » Modeling » UML2 » Re: Problem with redefining enum property
| Re: Problem with redefining enum property [message #474727] |
Thu, 26 July 2007 18:26  |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Andreas,
It's not possible to define a new enumeration based on an existing one
since Java has no concept of one enumeration restricting or extending
another. So to me it seems that you can't expect this concept to map
properly onto Java. It's best to ask about this on the UML2 newsgroup,
because I don't understand some of these concepts very well, so I've
added it to the "to" list of the reply.
Andreas Werner wrote:
> Hi newsgroup,
>
> I have created a uml metamodel containing a class X that extends
> uml::Class from the UML2 metamodel. In X I redefined the property
> visibility : VisibilityKind, which is initially defined in
> uml::PackagableElement. Therefore I created a new Enumeration
> NewVisibilityKind which extends VisibilityKind and put it into X as a
> redefining type for visibility. So far in the UML World everything
> works fine!
> But if I create an Ecore model from it, the problem is that
> NewVisibilityKind is not defined as a sub type from VibilityKind but
> an enum. Thus the generated code won't work, because the getter for
> NewVisibilityKind is not returning an instance of VisibilotyKind!
>
> Does anyone know a workaround for this issue?
> Please help, Andreas
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem with redefining enum property [message #474728 is a reply to message #474727] |
Thu, 26 July 2007 20:16  |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
In UML, Enumerations are DataTypes and DataTypes are Classifiers.
Classifiers in UML can have generalizations ( as you've discovered ),
however, as Ed mentions, in Java and in EMF 'enum A' cannot extend 'enum B'.
Languages other than Java might support such a thing which is why it is
possible in UML.
Because of this, UML2EcoreConverter maps uml:Enumeration to EEnum and drops
the uml generalization ( since there is no Ecore mapping ).
I'm not sure what to suggest in terms of fixing your problem, you could
redefine all the items in a new enumeration and use the new one but that
might not be exactly what you are looking for. Also, keep in mind that a
class cannot extend an enumeration in Java so trying to 'trick' the
converter by using a class that extends an enum probably won't work.
- James.
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:f8ap0f$v8g$1@build.eclipse.org...
> Andreas,
>
> It's not possible to define a new enumeration based on an existing one
> since Java has no concept of one enumeration restricting or extending
> another. So to me it seems that you can't expect this concept to map
> properly onto Java. It's best to ask about this on the UML2 newsgroup,
> because I don't understand some of these concepts very well, so I've
> added it to the "to" list of the reply.
>
>
> Andreas Werner wrote:
> > Hi newsgroup,
> >
> > I have created a uml metamodel containing a class X that extends
> > uml::Class from the UML2 metamodel. In X I redefined the property
> > visibility : VisibilityKind, which is initially defined in
> > uml::PackagableElement. Therefore I created a new Enumeration
> > NewVisibilityKind which extends VisibilityKind and put it into X as a
> > redefining type for visibility. So far in the UML World everything
> > works fine!
> > But if I create an Ecore model from it, the problem is that
> > NewVisibilityKind is not defined as a sub type from VibilityKind but
> > an enum. Thus the generated code won't work, because the getter for
> > NewVisibilityKind is not returning an instance of VisibilotyKind!
> >
> > Does anyone know a workaround for this issue?
> > Please help, Andreas
> >
> >
|
|
|
| Re: Problem with redefining enum property [message #474729 is a reply to message #474728] |
Thu, 26 July 2007 22:26 |
Andreas Werner
Messages: 55
Registered: July 2009 |
Member |
|
|
Hello James,
thanks for your reply!
Umm, what a pity, that there is obviously no beautiful solution!
Perhaps Sun will make enum types extensible in the future? ;)
OK, in the meantime I've found a simple workaround...
Andreas
> In UML, Enumerations are DataTypes and DataTypes are Classifiers.
> Classifiers in UML can have generalizations ( as you've discovered ),
> however, as Ed mentions, in Java and in EMF 'enum A' cannot extend
> 'enum B'. Languages other than Java might support such a thing which
> is why it is possible in UML.
>
> Because of this, UML2EcoreConverter maps uml:Enumeration to EEnum and
> drops the uml generalization ( since there is no Ecore mapping ).
>
> I'm not sure what to suggest in terms of fixing your problem, you
> could redefine all the items in a new enumeration and use the new one
> but that might not be exactly what you are looking for. Also, keep
> in mind that a class cannot extend an enumeration in Java so trying to
> 'trick' the converter by using a class that extends an enum probably
> won't work.
>
> - James.
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:f8ap0f$v8g$1@build.eclipse.org...
>> Andreas,
>>
>> It's not possible to define a new enumeration based on an existing
>> one since Java has no concept of one enumeration restricting or
>> extending another. So to me it seems that you can't expect this
>> concept to map properly onto Java. It's best to ask about this on
>> the UML2 newsgroup, because I don't understand some of these concepts
>> very well, so I've added it to the "to" list of the reply.
>>
>> Andreas Werner wrote:
>>
>>> Hi newsgroup,
>>>
>>> I have created a uml metamodel containing a class X that extends
>>> uml::Class from the UML2 metamodel. In X I redefined the property
>>> visibility : VisibilityKind, which is initially defined in
>>> uml::PackagableElement. Therefore I created a new Enumeration
>>> NewVisibilityKind which extends VisibilityKind and put it into X as
>>> a
>>> redefining type for visibility. So far in the UML World everything
>>> works fine!
>>> But if I create an Ecore model from it, the problem is that
>>> NewVisibilityKind is not defined as a sub type from VibilityKind but
>>> an enum. Thus the generated code won't work, because the getter for
>>> NewVisibilityKind is not returning an instance of VisibilotyKind!
>>> Does anyone know a workaround for this issue?
>>> Please help, Andreas
|
|
|
| Re: Problem with redefining enum property [message #474731 is a reply to message #474729] |
Fri, 27 July 2007 12:32 |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Andreas,
I hope that Sun doesn't! The whole point of an enum is that it defines a
finite and fixed number of values, so that clients will never see values
that they don't expect. If an enum were extensible, then its extent would
be dynamically expandable (as class can be obtained dynamically in various
ways in Java).
I don't understand why Enumerations in UML can be specialized. There ought
to be a constraint preventing this (and not just for Java's sake).
Just my $0.02,
Christian
Andreas Werner wrote:
> Hello James,
>
> thanks for your reply!
> Umm, what a pity, that there is obviously no beautiful solution!
> Perhaps Sun will make enum types extensible in the future? ;)
>
> OK, in the meantime I've found a simple workaround...
>
> Andreas
<snip>
|
|
|
| Re: Problem with redefining enum property [message #474732 is a reply to message #474731] |
Fri, 27 July 2007 13:05 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010903000505090008030703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
The only sensible subtype/specialization rule for enums would be that a
derived enum *restricts *the enumerators already available in the base
enum and that would imply that instances of the more derived
(restricted) enum would be instances of the base (less restricted enum),
but not vice versa, so using the keyword "extends" would certainly lead
to nonsense.
Does UML really allow one to expand the set of enumerators? That seems
incoherent...
Christian W. Damus wrote:
> Hi, Andreas,
>
> I hope that Sun doesn't! The whole point of an enum is that it defines a
> finite and fixed number of values, so that clients will never see values
> that they don't expect. If an enum were extensible, then its extent would
> be dynamically expandable (as class can be obtained dynamically in various
> ways in Java).
>
> I don't understand why Enumerations in UML can be specialized. There ought
> to be a constraint preventing this (and not just for Java's sake).
>
> Just my $0.02,
>
> Christian
>
>
> Andreas Werner wrote:
>
>
>> Hello James,
>>
>> thanks for your reply!
>> Umm, what a pity, that there is obviously no beautiful solution!
>> Perhaps Sun will make enum types extensible in the future? ;)
>>
>> OK, in the meantime I've found a simple workaround...
>>
>> Andreas
>>
>
> <snip>
>
--------------010903000505090008030703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
The only sensible subtype/specialization rule for enums would be that a
derived enum <b>restricts </b>the enumerators already available in
the base enum and that would imply that instances of the more derived
(restricted) enum would be instances of the base (less restricted
enum), but not vice versa, so using the keyword "extends" would
certainly lead to nonsense. <br>
<br>
Does UML really allow one to expand the set of enumerators? That seems
incoherent...<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:f8colr$b22$1@build.eclipse.org" type="cite">
<pre wrap="">Hi, Andreas,
I hope that Sun doesn't! The whole point of an enum is that it defines a
finite and fixed number of values, so that clients will never see values
that they don't expect. If an enum were extensible, then its extent would
be dynamically expandable (as class can be obtained dynamically in various
ways in Java).
I don't understand why Enumerations in UML can be specialized. There ought
to be a constraint preventing this (and not just for Java's sake).
Just my $0.02,
Christian
Andreas Werner wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello James,
thanks for your reply!
Umm, what a pity, that there is obviously no beautiful solution!
Perhaps Sun will make enum types extensible in the future? ;)
OK, in the meantime I've found a simple workaround...
Andreas
</pre>
</blockquote>
<pre wrap=""><!---->
<snip>
</pre>
</blockquote>
<br>
</body>
</html>
--------------010903000505090008030703--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem with redefining enum property [message #474734 is a reply to message #474732] |
Fri, 27 July 2007 14:01 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0026_01C7D035.1E602510
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Ed,
I believe that UML really allows one to expand the set of enumerators. =
I can't find any restrictions on this in the spec or otherwise. =20
The fact that this seems a little "incoherent" is not a big shocker ... =
UML has many quirks and sometimes inadvertent side affects of inheriting =
capabilities 'unintentially'. =20
EnumerationLiterals for example are PackageableElements by virtue of =
being InstanceSpecifications. As a result, EnumerationLiterals could =
potentially be owned by a Package ... doesn't make a whole lot of sense =
to me. Perhaps someone smarter than me can explain that one ( it =
shouldn't be too hard to find such a person :) ).
Cheers,
- James.
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:f8cqk2$hfd$1@build.eclipse.org...
Christian,
The only sensible subtype/specialization rule for enums would be that =
a derived enum restricts the enumerators already available in the base =
enum and that would imply that instances of the more derived =
(restricted) enum would be instances of the base (less restricted enum), =
but not vice versa, so using the keyword "extends" would certainly lead =
to nonsense. =20
Does UML really allow one to expand the set of enumerators? That =
seems incoherent...
Christian W. Damus wrote:=20
Hi, Andreas,
I hope that Sun doesn't! The whole point of an enum is that it defines =
a
finite and fixed number of values, so that clients will never see values
that they don't expect. If an enum were extensible, then its extent =
would
be dynamically expandable (as class can be obtained dynamically in =
various
ways in Java).
I don't understand why Enumerations in UML can be specialized. There =
ought
to be a constraint preventing this (and not just for Java's sake).
Just my $0.02,
Christian
Andreas Werner wrote:
Hello James,
thanks for your reply!
Umm, what a pity, that there is obviously no beautiful solution!
Perhaps Sun will make enum types extensible in the future? ;)
OK, in the meantime I've found a simple workaround...
Andreas
=20
<snip>
=20
------=_NextPart_000_0026_01C7D035.1E602510
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I believe that UML really allows one to =
expand the=20
set of enumerators. I can't find any restrictions on this in the =
spec or=20
otherwise. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The fact that this seems a little =
"incoherent" is=20
not a big shocker ... UML has many quirks and sometimes inadvertent side =
affects=20
of inheriting capabilities 'unintentially'. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>EnumerationLiterals for example are=20
PackageableElements by virtue of being =
InstanceSpecifications. As a=20
result, EnumerationLiterals could potentially be owned by a Package ... =
doesn't=20
make a whole lot of sense to me. Perhaps someone smarter =
than me can=20
explain that one ( it shouldn't be too hard to find such a person :)=20
).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Cheers,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
href=3D"news:f8cqk2$hfd$1@build.eclipse.org">news:f8cqk2$hfd$1@build.ecli=
pse.org</A>...</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">Christian,<BR><BR>The =
only sensible subtype/specialization rule for enums would be that a =
derived=20
enum <B>restricts </B>the enumerators already available in the base =
enum and=20
that would imply that instances of the more derived (restricted) enum =
would be=20
instances of the base (less restricted enum), but not vice versa, so =
using the=20
keyword "extends" would certainly lead to nonsense. <BR><BR>Does =
UML=20
really allow one to expand the set of enumerators? That seems=20
incoherent...<BR><BR><BR>Christian W. Damus wrote:=20
<BLOCKQUOTE cite=3Dmid:f8colr$b22$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hi, Andreas,
I hope that Sun doesn't! The whole point of an enum is that it defines =
a
finite and fixed number of values, so that clients will never see values
that they don't expect. If an enum were extensible, then its extent =
would
be dynamically expandable (as class can be obtained dynamically in =
various
ways in Java).
I don't understand why Enumerations in UML can be specialized. There =
ought
to be a constraint preventing this (and not just for Java's sake).
Just my $0.02,
Christian
Andreas Werner wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello James,
thanks for your reply!
Umm, what a pity, that there is obviously no beautiful solution!
Perhaps Sun will make enum types extensible in the future? ;)
OK, in the meantime I've found a simple workaround...
Andreas
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
<snip>
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0026_01C7D035.1E602510--
|
|
|
| Re: Problem with redefining enum property [message #474736 is a reply to message #474732] |
Fri, 27 July 2007 14:30 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed,
I can certainly see the utility in restricting the original set of values,
but they wouldn't be instances of the specializing enumeration type,
because they must be the *identical* instances as defined by the supertype.
Because the specializing enumeration would, itself, not have any literals,
it couldn't actually be used effectively as the type of a
property/parameter/etc. There wouldn't ever be any values conforming to
that type.
Cheers,
Christian
Ed Merks wrote:
> Christian,
>
> The only sensible subtype/specialization rule for enums would be that a
> derived enum *restricts *the enumerators already available in the base
> enum and that would imply that instances of the more derived
> (restricted) enum would be instances of the base (less restricted enum),
> but not vice versa, so using the keyword "extends" would certainly lead
> to nonsense.
>
> Does UML really allow one to expand the set of enumerators? That seems
> incoherent...
>
<snip>
|
|
|
| Re: Problem with redefining enum property [message #474739 is a reply to message #474731] |
Fri, 27 July 2007 18:05 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Christian,
I agree that there should be a constraint guarding against this, because it
does not make a whole lot of sense in practice... We'll raise an issue with
the OMG.
Kenn
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:f8colr$b22$1@build.eclipse.org...
> Hi, Andreas,
>
> I hope that Sun doesn't! The whole point of an enum is that it defines a
> finite and fixed number of values, so that clients will never see values
> that they don't expect. If an enum were extensible, then its extent would
> be dynamically expandable (as class can be obtained dynamically in various
> ways in Java).
>
> I don't understand why Enumerations in UML can be specialized. There
> ought
> to be a constraint preventing this (and not just for Java's sake).
>
> Just my $0.02,
>
> Christian
>
>
> Andreas Werner wrote:
>
>> Hello James,
>>
>> thanks for your reply!
>> Umm, what a pity, that there is obviously no beautiful solution!
>> Perhaps Sun will make enum types extensible in the future? ;)
>>
>> OK, in the meantime I've found a simple workaround...
>>
>> Andreas
>
> <snip>
|
|
|
| Re: Problem with redefining enum property [message #474740 is a reply to message #474739] |
Fri, 27 July 2007 19:02 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Thanks, Kenn! I'll be interested to find out whether this was a deliberate
choice by OMG ...
Cheers,
Christian
Kenn Hussey wrote:
> Christian,
>
> I agree that there should be a constraint guarding against this, because
> it does not make a whole lot of sense in practice... We'll raise an issue
> with the OMG.
>
> Kenn
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:f8colr$b22$1@build.eclipse.org...
>> Hi, Andreas,
>>
>> I hope that Sun doesn't! The whole point of an enum is that it defines a
>> finite and fixed number of values, so that clients will never see values
>> that they don't expect. If an enum were extensible, then its extent
>> would be dynamically expandable (as class can be obtained dynamically in
>> various ways in Java).
>>
>> I don't understand why Enumerations in UML can be specialized. There
>> ought
>> to be a constraint preventing this (and not just for Java's sake).
>>
>> Just my $0.02,
>>
>> Christian
<snip>
|
|
|
| Re: Problem with redefining enum property [message #475150 is a reply to message #474729] |
Tue, 21 August 2007 13:29 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
Hi Andreas,
I've stumbled across something that might be of use to you. From the book
"Thinking in Java" p. 1022.
They have an example like this.
public interface Food {
enum Appetizer implements Food {
SALAD, SOUP, SPRING_ROLLS;
}
enum MainCourse implements Food {
LSAGNE, BURRITO, LENTILS;
}
}
So you can do things like :
Food food = Appetizer.SALAD;
food = MainCourse.LASAGNE;
You can also create enums that implement interfaces.
This is not exactly what you were looking for but it might give you some
other ideas.
- James.
"Andreas Werner" <andreas.werner@itso-berlin.de> wrote in message
news:a5801389e7b78c99dfbe038576a@news.eclipse.org...
> Hello James,
>
> thanks for your reply!
> Umm, what a pity, that there is obviously no beautiful solution!
> Perhaps Sun will make enum types extensible in the future? ;)
>
> OK, in the meantime I've found a simple workaround...
>
> Andreas
>
> > In UML, Enumerations are DataTypes and DataTypes are Classifiers.
> > Classifiers in UML can have generalizations ( as you've discovered ),
> > however, as Ed mentions, in Java and in EMF 'enum A' cannot extend
> > 'enum B'. Languages other than Java might support such a thing which
> > is why it is possible in UML.
> >
> > Because of this, UML2EcoreConverter maps uml:Enumeration to EEnum and
> > drops the uml generalization ( since there is no Ecore mapping ).
> >
> > I'm not sure what to suggest in terms of fixing your problem, you
> > could redefine all the items in a new enumeration and use the new one
> > but that might not be exactly what you are looking for. Also, keep
> > in mind that a class cannot extend an enumeration in Java so trying to
> > 'trick' the converter by using a class that extends an enum probably
> > won't work.
> >
> > - James.
> >
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:f8ap0f$v8g$1@build.eclipse.org...
> >> Andreas,
> >>
> >> It's not possible to define a new enumeration based on an existing
> >> one since Java has no concept of one enumeration restricting or
> >> extending another. So to me it seems that you can't expect this
> >> concept to map properly onto Java. It's best to ask about this on
> >> the UML2 newsgroup, because I don't understand some of these concepts
> >> very well, so I've added it to the "to" list of the reply.
> >>
> >> Andreas Werner wrote:
> >>
> >>> Hi newsgroup,
> >>>
> >>> I have created a uml metamodel containing a class X that extends
> >>> uml::Class from the UML2 metamodel. In X I redefined the property
> >>> visibility : VisibilityKind, which is initially defined in
> >>> uml::PackagableElement. Therefore I created a new Enumeration
> >>> NewVisibilityKind which extends VisibilityKind and put it into X as
> >>> a
> >>> redefining type for visibility. So far in the UML World everything
> >>> works fine!
> >>> But if I create an Ecore model from it, the problem is that
> >>> NewVisibilityKind is not defined as a sub type from VibilityKind but
> >>> an enum. Thus the generated code won't work, because the getter for
> >>> NewVisibilityKind is not returning an instance of VisibilotyKind!
> >>> Does anyone know a workaround for this issue?
> >>> Please help, Andreas
>
>
|
|
|
| Re: Problem with redefining enum property [message #624094 is a reply to message #474727] |
Thu, 26 July 2007 20:16 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
In UML, Enumerations are DataTypes and DataTypes are Classifiers.
Classifiers in UML can have generalizations ( as you've discovered ),
however, as Ed mentions, in Java and in EMF 'enum A' cannot extend 'enum B'.
Languages other than Java might support such a thing which is why it is
possible in UML.
Because of this, UML2EcoreConverter maps uml:Enumeration to EEnum and drops
the uml generalization ( since there is no Ecore mapping ).
I'm not sure what to suggest in terms of fixing your problem, you could
redefine all the items in a new enumeration and use the new one but that
might not be exactly what you are looking for. Also, keep in mind that a
class cannot extend an enumeration in Java so trying to 'trick' the
converter by using a class that extends an enum probably won't work.
- James.
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:f8ap0f$v8g$1@build.eclipse.org...
> Andreas,
>
> It's not possible to define a new enumeration based on an existing one
> since Java has no concept of one enumeration restricting or extending
> another. So to me it seems that you can't expect this concept to map
> properly onto Java. It's best to ask about this on the UML2 newsgroup,
> because I don't understand some of these concepts very well, so I've
> added it to the "to" list of the reply.
>
>
> Andreas Werner wrote:
> > Hi newsgroup,
> >
> > I have created a uml metamodel containing a class X that extends
> > uml::Class from the UML2 metamodel. In X I redefined the property
> > visibility : VisibilityKind, which is initially defined in
> > uml::PackagableElement. Therefore I created a new Enumeration
> > NewVisibilityKind which extends VisibilityKind and put it into X as a
> > redefining type for visibility. So far in the UML World everything
> > works fine!
> > But if I create an Ecore model from it, the problem is that
> > NewVisibilityKind is not defined as a sub type from VibilityKind but
> > an enum. Thus the generated code won't work, because the getter for
> > NewVisibilityKind is not returning an instance of VisibilotyKind!
> >
> > Does anyone know a workaround for this issue?
> > Please help, Andreas
> >
> >
|
|
|
| Re: Problem with redefining enum property [message #624095 is a reply to message #474728] |
Thu, 26 July 2007 22:26 |
Andreas Werner
Messages: 55
Registered: July 2009 |
Member |
|
|
Hello James,
thanks for your reply!
Umm, what a pity, that there is obviously no beautiful solution!
Perhaps Sun will make enum types extensible in the future? ;)
OK, in the meantime I've found a simple workaround...
Andreas
> In UML, Enumerations are DataTypes and DataTypes are Classifiers.
> Classifiers in UML can have generalizations ( as you've discovered ),
> however, as Ed mentions, in Java and in EMF 'enum A' cannot extend
> 'enum B'. Languages other than Java might support such a thing which
> is why it is possible in UML.
>
> Because of this, UML2EcoreConverter maps uml:Enumeration to EEnum and
> drops the uml generalization ( since there is no Ecore mapping ).
>
> I'm not sure what to suggest in terms of fixing your problem, you
> could redefine all the items in a new enumeration and use the new one
> but that might not be exactly what you are looking for. Also, keep
> in mind that a class cannot extend an enumeration in Java so trying to
> 'trick' the converter by using a class that extends an enum probably
> won't work.
>
> - James.
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:f8ap0f$v8g$1@build.eclipse.org...
>> Andreas,
>>
>> It's not possible to define a new enumeration based on an existing
>> one since Java has no concept of one enumeration restricting or
>> extending another. So to me it seems that you can't expect this
>> concept to map properly onto Java. It's best to ask about this on
>> the UML2 newsgroup, because I don't understand some of these concepts
>> very well, so I've added it to the "to" list of the reply.
>>
>> Andreas Werner wrote:
>>
>>> Hi newsgroup,
>>>
>>> I have created a uml metamodel containing a class X that extends
>>> uml::Class from the UML2 metamodel. In X I redefined the property
>>> visibility : VisibilityKind, which is initially defined in
>>> uml::PackagableElement. Therefore I created a new Enumeration
>>> NewVisibilityKind which extends VisibilityKind and put it into X as
>>> a
>>> redefining type for visibility. So far in the UML World everything
>>> works fine!
>>> But if I create an Ecore model from it, the problem is that
>>> NewVisibilityKind is not defined as a sub type from VibilityKind but
>>> an enum. Thus the generated code won't work, because the getter for
>>> NewVisibilityKind is not returning an instance of VisibilotyKind!
>>> Does anyone know a workaround for this issue?
>>> Please help, Andreas
|
|
|
| Re: Problem with redefining enum property [message #624100 is a reply to message #474729] |
Fri, 27 July 2007 12:32 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Andreas,
I hope that Sun doesn't! The whole point of an enum is that it defines a
finite and fixed number of values, so that clients will never see values
that they don't expect. If an enum were extensible, then its extent would
be dynamically expandable (as class can be obtained dynamically in various
ways in Java).
I don't understand why Enumerations in UML can be specialized. There ought
to be a constraint preventing this (and not just for Java's sake).
Just my $0.02,
Christian
Andreas Werner wrote:
> Hello James,
>
> thanks for your reply!
> Umm, what a pity, that there is obviously no beautiful solution!
> Perhaps Sun will make enum types extensible in the future? ;)
>
> OK, in the meantime I've found a simple workaround...
>
> Andreas
<snip>
|
|
|
| Re: Problem with redefining enum property [message #624103 is a reply to message #474731] |
Fri, 27 July 2007 13:05 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010903000505090008030703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
The only sensible subtype/specialization rule for enums would be that a
derived enum *restricts *the enumerators already available in the base
enum and that would imply that instances of the more derived
(restricted) enum would be instances of the base (less restricted enum),
but not vice versa, so using the keyword "extends" would certainly lead
to nonsense.
Does UML really allow one to expand the set of enumerators? That seems
incoherent...
Christian W. Damus wrote:
> Hi, Andreas,
>
> I hope that Sun doesn't! The whole point of an enum is that it defines a
> finite and fixed number of values, so that clients will never see values
> that they don't expect. If an enum were extensible, then its extent would
> be dynamically expandable (as class can be obtained dynamically in various
> ways in Java).
>
> I don't understand why Enumerations in UML can be specialized. There ought
> to be a constraint preventing this (and not just for Java's sake).
>
> Just my $0.02,
>
> Christian
>
>
> Andreas Werner wrote:
>
>
>> Hello James,
>>
>> thanks for your reply!
>> Umm, what a pity, that there is obviously no beautiful solution!
>> Perhaps Sun will make enum types extensible in the future? ;)
>>
>> OK, in the meantime I've found a simple workaround...
>>
>> Andreas
>>
>
> <snip>
>
--------------010903000505090008030703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
The only sensible subtype/specialization rule for enums would be that a
derived enum <b>restricts </b>the enumerators already available in
the base enum and that would imply that instances of the more derived
(restricted) enum would be instances of the base (less restricted
enum), but not vice versa, so using the keyword "extends" would
certainly lead to nonsense. <br>
<br>
Does UML really allow one to expand the set of enumerators? That seems
incoherent...<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:f8colr$b22$1@build.eclipse.org" type="cite">
<pre wrap="">Hi, Andreas,
I hope that Sun doesn't! The whole point of an enum is that it defines a
finite and fixed number of values, so that clients will never see values
that they don't expect. If an enum were extensible, then its extent would
be dynamically expandable (as class can be obtained dynamically in various
ways in Java).
I don't understand why Enumerations in UML can be specialized. There ought
to be a constraint preventing this (and not just for Java's sake).
Just my $0.02,
Christian
Andreas Werner wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello James,
thanks for your reply!
Umm, what a pity, that there is obviously no beautiful solution!
Perhaps Sun will make enum types extensible in the future? ;)
OK, in the meantime I've found a simple workaround...
Andreas
</pre>
</blockquote>
<pre wrap=""><!---->
<snip>
</pre>
</blockquote>
<br>
</body>
</html>
--------------010903000505090008030703--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Problem with redefining enum property [message #624107 is a reply to message #474732] |
Fri, 27 July 2007 14:01 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0026_01C7D035.1E602510
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Ed,
I believe that UML really allows one to expand the set of enumerators. =
I can't find any restrictions on this in the spec or otherwise. =20
The fact that this seems a little "incoherent" is not a big shocker ... =
UML has many quirks and sometimes inadvertent side affects of inheriting =
capabilities 'unintentially'. =20
EnumerationLiterals for example are PackageableElements by virtue of =
being InstanceSpecifications. As a result, EnumerationLiterals could =
potentially be owned by a Package ... doesn't make a whole lot of sense =
to me. Perhaps someone smarter than me can explain that one ( it =
shouldn't be too hard to find such a person :) ).
Cheers,
- James.
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:f8cqk2$hfd$1@build.eclipse.org...
Christian,
The only sensible subtype/specialization rule for enums would be that =
a derived enum restricts the enumerators already available in the base =
enum and that would imply that instances of the more derived =
(restricted) enum would be instances of the base (less restricted enum), =
but not vice versa, so using the keyword "extends" would certainly lead =
to nonsense. =20
Does UML really allow one to expand the set of enumerators? That =
seems incoherent...
Christian W. Damus wrote:=20
Hi, Andreas,
I hope that Sun doesn't! The whole point of an enum is that it defines =
a
finite and fixed number of values, so that clients will never see values
that they don't expect. If an enum were extensible, then its extent =
would
be dynamically expandable (as class can be obtained dynamically in =
various
ways in Java).
I don't understand why Enumerations in UML can be specialized. There =
ought
to be a constraint preventing this (and not just for Java's sake).
Just my $0.02,
Christian
Andreas Werner wrote:
Hello James,
thanks for your reply!
Umm, what a pity, that there is obviously no beautiful solution!
Perhaps Sun will make enum types extensible in the future? ;)
OK, in the meantime I've found a simple workaround...
Andreas
=20
<snip>
=20
------=_NextPart_000_0026_01C7D035.1E602510
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I believe that UML really allows one to =
expand the=20
set of enumerators. I can't find any restrictions on this in the =
spec or=20
otherwise. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The fact that this seems a little =
"incoherent" is=20
not a big shocker ... UML has many quirks and sometimes inadvertent side =
affects=20
of inheriting capabilities 'unintentially'. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>EnumerationLiterals for example are=20
PackageableElements by virtue of being =
InstanceSpecifications. As a=20
result, EnumerationLiterals could potentially be owned by a Package ... =
doesn't=20
make a whole lot of sense to me. Perhaps someone smarter =
than me can=20
explain that one ( it shouldn't be too hard to find such a person :)=20
).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Cheers,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
href=3D"news:f8cqk2$hfd$1@build.eclipse.org">news:f8cqk2$hfd$1@build.ecli=
pse.org</A>...</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">Christian,<BR><BR>The =
only sensible subtype/specialization rule for enums would be that a =
derived=20
enum <B>restricts </B>the enumerators already available in the base =
enum and=20
that would imply that instances of the more derived (restricted) enum =
would be=20
instances of the base (less restricted enum), but not vice versa, so =
using the=20
keyword "extends" would certainly lead to nonsense. <BR><BR>Does =
UML=20
really allow one to expand the set of enumerators? That seems=20
incoherent...<BR><BR><BR>Christian W. Damus wrote:=20
<BLOCKQUOTE cite=3Dmid:f8colr$b22$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hi, Andreas,
I hope that Sun doesn't! The whole point of an enum is that it defines =
a
finite and fixed number of values, so that clients will never see values
that they don't expect. If an enum were extensible, then its extent =
would
be dynamically expandable (as class can be obtained dynamically in =
various
ways in Java).
I don't understand why Enumerations in UML can be specialized. There =
ought
to be a constraint preventing this (and not just for Java's sake).
Just my $0.02,
Christian
Andreas Werner wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hello James,
thanks for your reply!
Umm, what a pity, that there is obviously no beautiful solution!
Perhaps Sun will make enum types extensible in the future? ;)
OK, in the meantime I've found a simple workaround...
Andreas
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
<snip>
</PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0026_01C7D035.1E602510--
|
|
|
| Re: Problem with redefining enum property [message #624112 is a reply to message #474732] |
Fri, 27 July 2007 14:30 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed,
I can certainly see the utility in restricting the original set of values,
but they wouldn't be instances of the specializing enumeration type,
because they must be the *identical* instances as defined by the supertype.
Because the specializing enumeration would, itself, not have any literals,
it couldn't actually be used effectively as the type of a
property/parameter/etc. There wouldn't ever be any values conforming to
that type.
Cheers,
Christian
Ed Merks wrote:
> Christian,
>
> The only sensible subtype/specialization rule for enums would be that a
> derived enum *restricts *the enumerators already available in the base
> enum and that would imply that instances of the more derived
> (restricted) enum would be instances of the base (less restricted enum),
> but not vice versa, so using the keyword "extends" would certainly lead
> to nonsense.
>
> Does UML really allow one to expand the set of enumerators? That seems
> incoherent...
>
<snip>
|
|
|
| Re: Problem with redefining enum property [message #624115 is a reply to message #474731] |
Fri, 27 July 2007 18:05 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Christian,
I agree that there should be a constraint guarding against this, because it
does not make a whole lot of sense in practice... We'll raise an issue with
the OMG.
Kenn
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:f8colr$b22$1@build.eclipse.org...
> Hi, Andreas,
>
> I hope that Sun doesn't! The whole point of an enum is that it defines a
> finite and fixed number of values, so that clients will never see values
> that they don't expect. If an enum were extensible, then its extent would
> be dynamically expandable (as class can be obtained dynamically in various
> ways in Java).
>
> I don't understand why Enumerations in UML can be specialized. There
> ought
> to be a constraint preventing this (and not just for Java's sake).
>
> Just my $0.02,
>
> Christian
>
>
> Andreas Werner wrote:
>
>> Hello James,
>>
>> thanks for your reply!
>> Umm, what a pity, that there is obviously no beautiful solution!
>> Perhaps Sun will make enum types extensible in the future? ;)
>>
>> OK, in the meantime I've found a simple workaround...
>>
>> Andreas
>
> <snip>
|
|
|
| Re: Problem with redefining enum property [message #624116 is a reply to message #474739] |
Fri, 27 July 2007 19:02 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Thanks, Kenn! I'll be interested to find out whether this was a deliberate
choice by OMG ...
Cheers,
Christian
Kenn Hussey wrote:
> Christian,
>
> I agree that there should be a constraint guarding against this, because
> it does not make a whole lot of sense in practice... We'll raise an issue
> with the OMG.
>
> Kenn
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:f8colr$b22$1@build.eclipse.org...
>> Hi, Andreas,
>>
>> I hope that Sun doesn't! The whole point of an enum is that it defines a
>> finite and fixed number of values, so that clients will never see values
>> that they don't expect. If an enum were extensible, then its extent
>> would be dynamically expandable (as class can be obtained dynamically in
>> various ways in Java).
>>
>> I don't understand why Enumerations in UML can be specialized. There
>> ought
>> to be a constraint preventing this (and not just for Java's sake).
>>
>> Just my $0.02,
>>
>> Christian
<snip>
|
|
|
| Re: Problem with redefining enum property [message #624430 is a reply to message #474729] |
Tue, 21 August 2007 13:29 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
Hi Andreas,
I've stumbled across something that might be of use to you. From the book
"Thinking in Java" p. 1022.
They have an example like this.
public interface Food {
enum Appetizer implements Food {
SALAD, SOUP, SPRING_ROLLS;
}
enum MainCourse implements Food {
LSAGNE, BURRITO, LENTILS;
}
}
So you can do things like :
Food food = Appetizer.SALAD;
food = MainCourse.LASAGNE;
You can also create enums that implement interfaces.
This is not exactly what you were looking for but it might give you some
other ideas.
- James.
"Andreas Werner" <andreas.werner@itso-berlin.de> wrote in message
news:a5801389e7b78c99dfbe038576a@news.eclipse.org...
> Hello James,
>
> thanks for your reply!
> Umm, what a pity, that there is obviously no beautiful solution!
> Perhaps Sun will make enum types extensible in the future? ;)
>
> OK, in the meantime I've found a simple workaround...
>
> Andreas
>
> > In UML, Enumerations are DataTypes and DataTypes are Classifiers.
> > Classifiers in UML can have generalizations ( as you've discovered ),
> > however, as Ed mentions, in Java and in EMF 'enum A' cannot extend
> > 'enum B'. Languages other than Java might support such a thing which
> > is why it is possible in UML.
> >
> > Because of this, UML2EcoreConverter maps uml:Enumeration to EEnum and
> > drops the uml generalization ( since there is no Ecore mapping ).
> >
> > I'm not sure what to suggest in terms of fixing your problem, you
> > could redefine all the items in a new enumeration and use the new one
> > but that might not be exactly what you are looking for. Also, keep
> > in mind that a class cannot extend an enumeration in Java so trying to
> > 'trick' the converter by using a class that extends an enum probably
> > won't work.
> >
> > - James.
> >
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:f8ap0f$v8g$1@build.eclipse.org...
> >> Andreas,
> >>
> >> It's not possible to define a new enumeration based on an existing
> >> one since Java has no concept of one enumeration restricting or
> >> extending another. So to me it seems that you can't expect this
> >> concept to map properly onto Java. It's best to ask about this on
> >> the UML2 newsgroup, because I don't understand some of these concepts
> >> very well, so I've added it to the "to" list of the reply.
> >>
> >> Andreas Werner wrote:
> >>
> >>> Hi newsgroup,
> >>>
> >>> I have created a uml metamodel containing a class X that extends
> >>> uml::Class from the UML2 metamodel. In X I redefined the property
> >>> visibility : VisibilityKind, which is initially defined in
> >>> uml::PackagableElement. Therefore I created a new Enumeration
> >>> NewVisibilityKind which extends VisibilityKind and put it into X as
> >>> a
> >>> redefining type for visibility. So far in the UML World everything
> >>> works fine!
> >>> But if I create an Ecore model from it, the problem is that
> >>> NewVisibilityKind is not defined as a sub type from VibilityKind but
> >>> an enum. Thus the generated code won't work, because the getter for
> >>> NewVisibilityKind is not returning an instance of VisibilotyKind!
> >>> Does anyone know a workaround for this issue?
> >>> Please help, Andreas
>
>
|
|
|
Goto Forum:
Current Time: Sat Apr 27 01:56:24 GMT 2024
Powered by FUDForum. Page generated in 0.04542 seconds |
] 
Search
Help
Register
Login
Home
