Home » Modeling » UML2 » Enumeration Default Value
| |
| Re: Enumeration Default Value [message #477813 is a reply to message #477811] |
Fri, 10 October 2008 22:00   |
 Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070507020107030505020804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Kenn,
You can define an EDataType whose instance class in the enum's class and
that data type will allow nulls.
Kenn Hussey wrote:
> Alexandre,
>
> This is a side-effect of the fact that Ecore (from EMF) is used to represent
> the metadata for (defined) profiles - in Ecore, an enumeration, like
> primitive (data) types, must have an implicit default. Unfortunately, I
> don't think there's much that can be done to change this. :(
>
> Kenn
>
> "Alexandre Torres" <alexandre.torres@gmail.com> wrote in message
> news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org...
>
>> Hi.
>> I created a profile where one of the stereotype properties points to an
>> enumeraton. The property is set as [0..1] with default value null literal.
>> But it's just impossible to set a null value to this property. When the
>> profile is defined (define menu) it chooses one of the literals as an
>> arbitrary default value.
>> How can I create a property that accept nulls with Enumerations ?
>>
>> Thanks
>>
>>
>>
>>
>
>
>
--------------070507020107030505020804
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">
Kenn,<br>
<br>
You can define an EDataType whose instance class in the enum's class
and that data type will allow nulls.<br>
<br>
<br>
Kenn Hussey wrote:
<blockquote cite="mid:gcofbg$mft$1@build.eclipse.org" type="cite">
<pre wrap="">Alexandre,
This is a side-effect of the fact that Ecore (from EMF) is used to represent
the metadata for (defined) profiles - in Ecore, an enumeration, like
primitive (data) types, must have an implicit default. Unfortunately, I
don't think there's much that can be done to change this. :(
Kenn
"Alexandre Torres" <a class="moz-txt-link-rfc2396E" href="mailto:alexandre.torres@gmail.com"><alexandre.torres@gmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org">news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi.
I created a profile where one of the stereotype properties points to an
enumeraton. The property is set as [0..1] with default value null literal.
But it's just impossible to set a null value to this property. When the
profile is defined (define menu) it chooses one of the literals as an
arbitrary default value.
How can I create a property that accept nulls with Enumerations ?
Thanks
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------070507020107030505020804--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Enumeration Default Value [message #477825 is a reply to message #477813] |
Tue, 14 October 2008 20:24 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_00AC_01C92E19.49F54280
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
OK, but the literals of the enumeration won't be supported in the same =
way as they are for enumerations... and I assume serialization support =
for such a data type would need to be implemented?
Kenn
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:gcojar$3th$1@build.eclipse.org...
Kenn,
You can define an EDataType whose instance class in the enum's class =
and that data type will allow nulls.
Kenn Hussey wrote:=20
Alexandre,
This is a side-effect of the fact that Ecore (from EMF) is used to =
represent=20
the metadata for (defined) profiles - in Ecore, an enumeration, like=20
primitive (data) types, must have an implicit default. Unfortunately, I=20
don't think there's much that can be done to change this. :(
Kenn
"Alexandre Torres" <alexandre.torres@gmail.com> wrote in message=20
news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org...
Hi.
I created a profile where one of the stereotype properties points to an=20
enumeraton. The property is set as [0..1] with default value null =
literal.
But it's just impossible to set a null value to this property. When the=20
profile is defined (define menu) it chooses one of the literals as an=20
arbitrary default value.
How can I create a property that accept nulls with Enumerations ?
Thanks
=20
------=_NextPart_000_00AC_01C92E19.49F54280
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.6000.16705" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>OK, but the literals of the enumeration =
won't be=20
supported in the same way as they are for enumerations... and I assume=20
serialization support for such a data type would need to be=20
implemented?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Kenn</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:gcojar$3th$1@build.eclipse.org">news:gcojar$3th$1@build.ecli=
pse.org</A>...</DIV>Kenn,<BR><BR>You=20
can define an EDataType whose instance class in the enum's class and =
that data=20
type will allow nulls.<BR><BR><BR>Kenn Hussey wrote:=20
<BLOCKQUOTE cite=3Dmid:gcofbg$mft$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Alexandre,
This is a side-effect of the fact that Ecore (from EMF) is used to =
represent=20
the metadata for (defined) profiles - in Ecore, an enumeration, like=20
primitive (data) types, must have an implicit default. Unfortunately, I=20
don't think there's much that can be done to change this. :(
Kenn
"Alexandre Torres" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:alexandre.torres@gmail.com"><alexandre.torres@gmail.com=
></A> wrote in message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org">news:c08=
3e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi.
I created a profile where one of the stereotype properties points to an=20
enumeraton. The property is set as [0..1] with default value null =
literal.
But it's just impossible to set a null value to this property. When the=20
profile is defined (define menu) it chooses one of the literals as an=20
arbitrary default value.
How can I create a property that accept nulls with Enumerations ?
Thanks
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_00AC_01C92E19.49F54280--
|
|
|
| Re: Enumeration Default Value [message #477847 is a reply to message #477825] |
Mon, 20 October 2008 11:17 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060901000201090302030601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Kenn,
If do it in just the right magical way, it will work. :-P I.e., when
generating an EEnum from an enumeration facet in XML Schema (or any
EDataType who's type is primitive), we always need to generate a second
data type that allows null in case the type is ever used for a nillable
element. Serialization an validation is properly supported for this
automatically. You might be right that the combo box won't be correct,
but hey, no one has complained about that; if they did, it would be
fixed by now...
Kenn Hussey wrote:
> OK, but the literals of the enumeration won't be supported in the same
> way as they are for enumerations... and I assume serialization support
> for such a data type would need to be implemented?
>
> Kenn
>
> "Ed Merks" <Ed.Merks@gmail.com <mailto:Ed.Merks@gmail.com>> wrote
> in message news:gcojar$3th$1@build.eclipse.org...
> Kenn,
>
> You can define an EDataType whose instance class in the enum's
> class and that data type will allow nulls.
>
>
> Kenn Hussey wrote:
>> Alexandre,
>>
>> This is a side-effect of the fact that Ecore (from EMF) is used to represent
>> the metadata for (defined) profiles - in Ecore, an enumeration, like
>> primitive (data) types, must have an implicit default. Unfortunately, I
>> don't think there's much that can be done to change this. :(
>>
>> Kenn
>>
>> "Alexandre Torres" <alexandre.torres@gmail.com> wrote in message
>> news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org...
>>
>>> Hi.
>>> I created a profile where one of the stereotype properties points to an
>>> enumeraton. The property is set as [0..1] with default value null literal.
>>> But it's just impossible to set a null value to this property. When the
>>> profile is defined (define menu) it chooses one of the literals as an
>>> arbitrary default value.
>>> How can I create a property that accept nulls with Enumerations ?
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>
>>
>>
>
--------------060901000201090302030601
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">
Kenn,<br>
<br>
If do it in just the right magical way, it will work. :-P I.e., when
generating an EEnum from an enumeration facet in XML Schema (or any
EDataType who's type is primitive), we always need to generate a second
data type that allows null in case the type is ever used for a nillable
element. Serialization an validation is properly supported for this
automatically. You might be right that the combo box won't be correct,
but hey, no one has complained about that; if they did, it would be
fixed by now...<br>
<br>
<br>
Kenn Hussey wrote:
<blockquote cite="mid:gd2v5b$sml$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.6000.16705" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">OK, but the literals of the
enumeration won't be supported in the same way as they are for
enumerations... and I assume serialization support for such a data type
would need to be implemented?</font></div>
<div> </div>
<div><font face="Arial" size="2">Kenn</font></div>
<blockquote dir="ltr"
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" <<a moz-do-not-send="true"
href="mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>> wrote in
message <a moz-do-not-send="true"
href="news:gcojar$3th$1@build.eclipse.org">news:gcojar$3th$1@build.eclipse.org</a>...</div>
Kenn,<br>
<br>
You can define an EDataType whose instance class in the enum's class
and that data type will allow nulls.<br>
<br>
<br>
Kenn Hussey wrote:
<blockquote cite="mid:gcofbg$mft$1@build.eclipse.org" type="cite">
<pre wrap="">Alexandre,
This is a side-effect of the fact that Ecore (from EMF) is used to represent
the metadata for (defined) profiles - in Ecore, an enumeration, like
primitive (data) types, must have an implicit default. Unfortunately, I
don't think there's much that can be done to change this. :(
Kenn
"Alexandre Torres" <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:alexandre.torres@gmail.com"><alexandre.torres@gmail.com></a> wrote in message
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org">news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi.
I created a profile where one of the stereotype properties points to an
enumeraton. The property is set as [0..1] with default value null literal.
But it's just impossible to set a null value to this property. When the
profile is defined (define menu) it chooses one of the literals as an
arbitrary default value.
How can I create a property that accept nulls with Enumerations ?
Thanks
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------060901000201090302030601--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Enumeration Default Value [message #477949 is a reply to message #477847] |
Sat, 08 November 2008 14:23 |
Alexandre Torres
Messages: 139
Registered: July 2009 |
Senior Member |
|
|
Lets revive this thread.
This is too another real problem, not being able to set primitive types as
null, like Boolean. If you read the UML spec you going to see that several
ocl rules are based upon nullable integer values like MultiplicityElement
lower bound:
From UML specification:
lowerBound = if lowerValue->isEmpty() then 1 else
lowerValue.integerValue() endif
so, lowerbound will never be empty when using uml2. Divergences like that
may seem small now, but in the long term make hard or impossible
interoperate models between tools.
And as pointed before, the lack of hability to say that some thing accept
nulls, leaving the decision about the value assumed to default values or
later check is important.
For instance, I can use default values to simulate the "unset" state, but,
if the default value changes, it's impossible to tell what situation the
user choose the value and what the situation where the user left it unset.
To make it worse, the unset state works very well for String and not
primitive types.
But if I add an wrapper as Ed proposed, this will make my model "strange".
Someone looking at my model will say "why you did it?" and I will have to
answer "becouse my uml toolkit has this limitation". All ocl rules will
had to be written to use wrappers, and will look alien to uml purists, and
bigger too.
Well i'm disappointed with this limitation. Someone that works with uml
should not be bound with those EMF problems (UML-MOF problems are already
a lot).
In the end I can't find any OMG uml tool that really implements the
specification with a good support for profile creation like eclipse's
implementation - what is only possible becouse of EMF's maturity. But EMF
will not evolve ?
Thanks
|
|
|
| Re: Enumeration Default Value [message #477950 is a reply to message #477949] |
Sat, 08 November 2008 14:59 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Alexandre,
Comments below.
Alexandre Torres wrote:
> Lets revive this thread.
I thought the horse was dead.
> This is too another real problem, not being able to set primitive
> types as null, like Boolean. If you read the UML spec you going to see
> that several ocl rules are based upon nullable integer values like
> MultiplicityElement lower bound:
> From UML specification:
> lowerBound = if lowerValue->isEmpty() then 1 else
> lowerValue.integerValue() endif
>
> so, lowerbound will never be empty when using uml2.
I suppose you could pick some meaningless value as representing empty...
> Divergences like that may seem small now, but in the long term make
> hard or impossible interoperate models between tools.
So really UML should have not used int but rather Integer? Or perhaps
BigInteger, because I'd expect there is no limit on the theoretical
range of all integers...
> And as pointed before, the lack of hability to say that some thing
> accept nulls, leaving the decision about the value assumed to default
> values or later check is important. For instance, I can use default
> values to simulate the "unset" state, but, if the default value
> changes, it's impossible to tell what situation the user choose the
> value and what the situation where the user left it unset.
EMF supports unsettable features to model the additional state.
> To make it worse, the unset state works very well for String and not
> primitive types.
No, not if you consider that you might want being set to null to be
different from null being the default. E.g., <x xsi:nil="true"/> verses
x being absent is often interpreted as two different states.
> But if I add an wrapper as Ed proposed, this will make my model
> "strange".
Unfortunately things like UML and XML Schema have things that are kind
of strange from a Java point of view.
> Someone looking at my model will say "why you did it?" and I will have
> to answer "becouse my uml toolkit has this limitation".
Or because Java has primitive types that are different from their
wrapper types...
> All ocl rules will had to be written to use wrappers, and will look
> alien to uml purists, and bigger too.
Not sure how it will look different in OCL. Do boolean and Boolean
look different for OCL?
> Well i'm disappointed with this limitation.
I'm not sure the limitation?
> Someone that works with uml should not be bound with those EMF
> problems (UML-MOF problems are already a lot).
It seems to me that UML as no notion of primitive types verses their
correspond boxed types the way Java does, so I imagine there will always
been some mismatch.
> In the end I can't find any OMG uml tool that really implements the
> specification with a good support for profile creation like eclipse's
> implementation - what is only possible becouse of EMF's maturity. But
> EMF will not evolve ?
While the UML specification might change in binary incompatible ways
every few years, that's not a choice I would make lightly with Ecore.
To support nillable elements in XML Schema, we already have very
reasonable support for enumeration values that can be assigned
null---it's just an EDataType wrapper and the generated API will look
identical---so if that's important to support, it's within easy reach
already.
>
> Thanks
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Enumeration Default Value [message #477975 is a reply to message #477949] |
Mon, 17 November 2008 08:28 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Alexandre,
To be fair, there is a difference between MultiplicityElement::lowerValue
and MultiplicityElement::lower; former is effectively typed by a "wrapper"
type and so is nullable, whereas the latter is typed by a primitive. So,
while MultiplicityElement::lowerBound() won't return null (since it too is
typed by a primitive), MultiplicityElement::getLowerValue() will - that's
why the OCL expression you mentioned references
MultiplicityElement::lowerValue instead of MultiplicityElement::lower.
These "limitations" you mention, at least in the case of profiles, arise
from the mapping of UML concepts to EMOF/Ecore concepts and from the fact
that some things which are expressable in Ecore (like whether a feature's
value has been set) aren't expressable in UML. To support an "unset" state
for stereotype properties, simply apply the Ecore profile and set the
EAttribute::isUnsettable tag to 'true'...
Kenn
"Alexandre Torres" <alexandre.torres@gmail.com> wrote in message
news:a5c037f8b73afdc4d389f096a9566494$1@www.eclipse.org...
> Lets revive this thread.
> This is too another real problem, not being able to set primitive types as
> null, like Boolean. If you read the UML spec you going to see that several
> ocl rules are based upon nullable integer values like MultiplicityElement
> lower bound:
> From UML specification:
> lowerBound = if lowerValue->isEmpty() then 1 else
> lowerValue.integerValue() endif
>
> so, lowerbound will never be empty when using uml2. Divergences like that
> may seem small now, but in the long term make hard or impossible
> interoperate models between tools. And as pointed before, the lack of
> hability to say that some thing accept nulls, leaving the decision about
> the value assumed to default values or later check is important. For
> instance, I can use default values to simulate the "unset" state, but, if
> the default value changes, it's impossible to tell what situation the user
> choose the value and what the situation where the user left it unset. To
> make it worse, the unset state works very well for String and not
> primitive types.
> But if I add an wrapper as Ed proposed, this will make my model "strange".
> Someone looking at my model will say "why you did it?" and I will have to
> answer "becouse my uml toolkit has this limitation". All ocl rules will
> had to be written to use wrappers, and will look alien to uml purists, and
> bigger too.
> Well i'm disappointed with this limitation. Someone that works with uml
> should not be bound with those EMF problems (UML-MOF problems are already
> a lot).
> In the end I can't find any OMG uml tool that really implements the
> specification with a good support for profile creation like eclipse's
> implementation - what is only possible becouse of EMF's maturity. But EMF
> will not evolve ?
>
> Thanks
>
|
|
| |
| Re: Enumeration Default Value [message #627010 is a reply to message #477811] |
Fri, 10 October 2008 22:00 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070507020107030505020804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Kenn,
You can define an EDataType whose instance class in the enum's class and
that data type will allow nulls.
Kenn Hussey wrote:
> Alexandre,
>
> This is a side-effect of the fact that Ecore (from EMF) is used to represent
> the metadata for (defined) profiles - in Ecore, an enumeration, like
> primitive (data) types, must have an implicit default. Unfortunately, I
> don't think there's much that can be done to change this. :(
>
> Kenn
>
> "Alexandre Torres" <alexandre.torres@gmail.com> wrote in message
> news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org...
>
>> Hi.
>> I created a profile where one of the stereotype properties points to an
>> enumeraton. The property is set as [0..1] with default value null literal.
>> But it's just impossible to set a null value to this property. When the
>> profile is defined (define menu) it chooses one of the literals as an
>> arbitrary default value.
>> How can I create a property that accept nulls with Enumerations ?
>>
>> Thanks
>>
>>
>>
>>
>
>
>
--------------070507020107030505020804
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">
Kenn,<br>
<br>
You can define an EDataType whose instance class in the enum's class
and that data type will allow nulls.<br>
<br>
<br>
Kenn Hussey wrote:
<blockquote cite="mid:gcofbg$mft$1@build.eclipse.org" type="cite">
<pre wrap="">Alexandre,
This is a side-effect of the fact that Ecore (from EMF) is used to represent
the metadata for (defined) profiles - in Ecore, an enumeration, like
primitive (data) types, must have an implicit default. Unfortunately, I
don't think there's much that can be done to change this. :(
Kenn
"Alexandre Torres" <a class="moz-txt-link-rfc2396E" href="mailto:alexandre.torres@gmail.com"><alexandre.torres@gmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org">news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi.
I created a profile where one of the stereotype properties points to an
enumeraton. The property is set as [0..1] with default value null literal.
But it's just impossible to set a null value to this property. When the
profile is defined (define menu) it chooses one of the literals as an
arbitrary default value.
How can I create a property that accept nulls with Enumerations ?
Thanks
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------070507020107030505020804--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Enumeration Default Value [message #627030 is a reply to message #477813] |
Tue, 14 October 2008 20:24 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_00AC_01C92E19.49F54280
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
OK, but the literals of the enumeration won't be supported in the same =
way as they are for enumerations... and I assume serialization support =
for such a data type would need to be implemented?
Kenn
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:gcojar$3th$1@build.eclipse.org...
Kenn,
You can define an EDataType whose instance class in the enum's class =
and that data type will allow nulls.
Kenn Hussey wrote:=20
Alexandre,
This is a side-effect of the fact that Ecore (from EMF) is used to =
represent=20
the metadata for (defined) profiles - in Ecore, an enumeration, like=20
primitive (data) types, must have an implicit default. Unfortunately, I=20
don't think there's much that can be done to change this. :(
Kenn
"Alexandre Torres" <alexandre.torres@gmail.com> wrote in message=20
news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org...
Hi.
I created a profile where one of the stereotype properties points to an=20
enumeraton. The property is set as [0..1] with default value null =
literal.
But it's just impossible to set a null value to this property. When the=20
profile is defined (define menu) it chooses one of the literals as an=20
arbitrary default value.
How can I create a property that accept nulls with Enumerations ?
Thanks
=20
------=_NextPart_000_00AC_01C92E19.49F54280
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.6000.16705" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>OK, but the literals of the enumeration =
won't be=20
supported in the same way as they are for enumerations... and I assume=20
serialization support for such a data type would need to be=20
implemented?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Kenn</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:gcojar$3th$1@build.eclipse.org">news:gcojar$3th$1@build.ecli=
pse.org</A>...</DIV>Kenn,<BR><BR>You=20
can define an EDataType whose instance class in the enum's class and =
that data=20
type will allow nulls.<BR><BR><BR>Kenn Hussey wrote:=20
<BLOCKQUOTE cite=3Dmid:gcofbg$mft$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Alexandre,
This is a side-effect of the fact that Ecore (from EMF) is used to =
represent=20
the metadata for (defined) profiles - in Ecore, an enumeration, like=20
primitive (data) types, must have an implicit default. Unfortunately, I=20
don't think there's much that can be done to change this. :(
Kenn
"Alexandre Torres" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:alexandre.torres@gmail.com"><alexandre.torres@gmail.com=
></A> wrote in message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org">news:c08=
3e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi.
I created a profile where one of the stereotype properties points to an=20
enumeraton. The property is set as [0..1] with default value null =
literal.
But it's just impossible to set a null value to this property. When the=20
profile is defined (define menu) it chooses one of the literals as an=20
arbitrary default value.
How can I create a property that accept nulls with Enumerations ?
Thanks
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_00AC_01C92E19.49F54280--
|
|
|
| Re: Enumeration Default Value [message #627050 is a reply to message #477825] |
Mon, 20 October 2008 11:17 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060901000201090302030601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Kenn,
If do it in just the right magical way, it will work. :-P I.e., when
generating an EEnum from an enumeration facet in XML Schema (or any
EDataType who's type is primitive), we always need to generate a second
data type that allows null in case the type is ever used for a nillable
element. Serialization an validation is properly supported for this
automatically. You might be right that the combo box won't be correct,
but hey, no one has complained about that; if they did, it would be
fixed by now...
Kenn Hussey wrote:
> OK, but the literals of the enumeration won't be supported in the same
> way as they are for enumerations... and I assume serialization support
> for such a data type would need to be implemented?
>
> Kenn
>
> "Ed Merks" <Ed.Merks@gmail.com <mailto:Ed.Merks@gmail.com>> wrote
> in message news:gcojar$3th$1@build.eclipse.org...
> Kenn,
>
> You can define an EDataType whose instance class in the enum's
> class and that data type will allow nulls.
>
>
> Kenn Hussey wrote:
>> Alexandre,
>>
>> This is a side-effect of the fact that Ecore (from EMF) is used to represent
>> the metadata for (defined) profiles - in Ecore, an enumeration, like
>> primitive (data) types, must have an implicit default. Unfortunately, I
>> don't think there's much that can be done to change this. :(
>>
>> Kenn
>>
>> "Alexandre Torres" <alexandre.torres@gmail.com> wrote in message
>> news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org...
>>
>>> Hi.
>>> I created a profile where one of the stereotype properties points to an
>>> enumeraton. The property is set as [0..1] with default value null literal.
>>> But it's just impossible to set a null value to this property. When the
>>> profile is defined (define menu) it chooses one of the literals as an
>>> arbitrary default value.
>>> How can I create a property that accept nulls with Enumerations ?
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>
>>
>>
>
--------------060901000201090302030601
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">
Kenn,<br>
<br>
If do it in just the right magical way, it will work. :-P I.e., when
generating an EEnum from an enumeration facet in XML Schema (or any
EDataType who's type is primitive), we always need to generate a second
data type that allows null in case the type is ever used for a nillable
element. Serialization an validation is properly supported for this
automatically. You might be right that the combo box won't be correct,
but hey, no one has complained about that; if they did, it would be
fixed by now...<br>
<br>
<br>
Kenn Hussey wrote:
<blockquote cite="mid:gd2v5b$sml$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.6000.16705" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">OK, but the literals of the
enumeration won't be supported in the same way as they are for
enumerations... and I assume serialization support for such a data type
would need to be implemented?</font></div>
<div> </div>
<div><font face="Arial" size="2">Kenn</font></div>
<blockquote dir="ltr"
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" <<a moz-do-not-send="true"
href="mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>> wrote in
message <a moz-do-not-send="true"
href="news:gcojar$3th$1@build.eclipse.org">news:gcojar$3th$1@build.eclipse.org</a>...</div>
Kenn,<br>
<br>
You can define an EDataType whose instance class in the enum's class
and that data type will allow nulls.<br>
<br>
<br>
Kenn Hussey wrote:
<blockquote cite="mid:gcofbg$mft$1@build.eclipse.org" type="cite">
<pre wrap="">Alexandre,
This is a side-effect of the fact that Ecore (from EMF) is used to represent
the metadata for (defined) profiles - in Ecore, an enumeration, like
primitive (data) types, must have an implicit default. Unfortunately, I
don't think there's much that can be done to change this. :(
Kenn
"Alexandre Torres" <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:alexandre.torres@gmail.com"><alexandre.torres@gmail.com></a> wrote in message
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org">news:c083e22b68ab5c671880a8c4bffc028b$1@www.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi.
I created a profile where one of the stereotype properties points to an
enumeraton. The property is set as [0..1] with default value null literal.
But it's just impossible to set a null value to this property. When the
profile is defined (define menu) it chooses one of the literals as an
arbitrary default value.
How can I create a property that accept nulls with Enumerations ?
Thanks
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------060901000201090302030601--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Enumeration Default Value [message #627161 is a reply to message #477847] |
Sat, 08 November 2008 14:23 |
Alexandre Torres
Messages: 139
Registered: July 2009 |
Senior Member |
|
|
Lets revive this thread.
This is too another real problem, not being able to set primitive types as
null, like Boolean. If you read the UML spec you going to see that several
ocl rules are based upon nullable integer values like MultiplicityElement
lower bound:
From UML specification:
lowerBound = if lowerValue->isEmpty() then 1 else
lowerValue.integerValue() endif
so, lowerbound will never be empty when using uml2. Divergences like that
may seem small now, but in the long term make hard or impossible
interoperate models between tools.
And as pointed before, the lack of hability to say that some thing accept
nulls, leaving the decision about the value assumed to default values or
later check is important.
For instance, I can use default values to simulate the "unset" state, but,
if the default value changes, it's impossible to tell what situation the
user choose the value and what the situation where the user left it unset.
To make it worse, the unset state works very well for String and not
primitive types.
But if I add an wrapper as Ed proposed, this will make my model "strange".
Someone looking at my model will say "why you did it?" and I will have to
answer "becouse my uml toolkit has this limitation". All ocl rules will
had to be written to use wrappers, and will look alien to uml purists, and
bigger too.
Well i'm disappointed with this limitation. Someone that works with uml
should not be bound with those EMF problems (UML-MOF problems are already
a lot).
In the end I can't find any OMG uml tool that really implements the
specification with a good support for profile creation like eclipse's
implementation - what is only possible becouse of EMF's maturity. But EMF
will not evolve ?
Thanks
|
|
|
| Re: Enumeration Default Value [message #627162 is a reply to message #477949] |
Sat, 08 November 2008 14:59 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Alexandre,
Comments below.
Alexandre Torres wrote:
> Lets revive this thread.
I thought the horse was dead.
> This is too another real problem, not being able to set primitive
> types as null, like Boolean. If you read the UML spec you going to see
> that several ocl rules are based upon nullable integer values like
> MultiplicityElement lower bound:
> From UML specification:
> lowerBound = if lowerValue->isEmpty() then 1 else
> lowerValue.integerValue() endif
>
> so, lowerbound will never be empty when using uml2.
I suppose you could pick some meaningless value as representing empty...
> Divergences like that may seem small now, but in the long term make
> hard or impossible interoperate models between tools.
So really UML should have not used int but rather Integer? Or perhaps
BigInteger, because I'd expect there is no limit on the theoretical
range of all integers...
> And as pointed before, the lack of hability to say that some thing
> accept nulls, leaving the decision about the value assumed to default
> values or later check is important. For instance, I can use default
> values to simulate the "unset" state, but, if the default value
> changes, it's impossible to tell what situation the user choose the
> value and what the situation where the user left it unset.
EMF supports unsettable features to model the additional state.
> To make it worse, the unset state works very well for String and not
> primitive types.
No, not if you consider that you might want being set to null to be
different from null being the default. E.g., <x xsi:nil="true"/> verses
x being absent is often interpreted as two different states.
> But if I add an wrapper as Ed proposed, this will make my model
> "strange".
Unfortunately things like UML and XML Schema have things that are kind
of strange from a Java point of view.
> Someone looking at my model will say "why you did it?" and I will have
> to answer "becouse my uml toolkit has this limitation".
Or because Java has primitive types that are different from their
wrapper types...
> All ocl rules will had to be written to use wrappers, and will look
> alien to uml purists, and bigger too.
Not sure how it will look different in OCL. Do boolean and Boolean
look different for OCL?
> Well i'm disappointed with this limitation.
I'm not sure the limitation?
> Someone that works with uml should not be bound with those EMF
> problems (UML-MOF problems are already a lot).
It seems to me that UML as no notion of primitive types verses their
correspond boxed types the way Java does, so I imagine there will always
been some mismatch.
> In the end I can't find any OMG uml tool that really implements the
> specification with a good support for profile creation like eclipse's
> implementation - what is only possible becouse of EMF's maturity. But
> EMF will not evolve ?
While the UML specification might change in binary incompatible ways
every few years, that's not a choice I would make lightly with Ecore.
To support nillable elements in XML Schema, we already have very
reasonable support for enumeration values that can be assigned
null---it's just an EDataType wrapper and the generated API will look
identical---so if that's important to support, it's within easy reach
already.
>
> Thanks
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Enumeration Default Value [message #627192 is a reply to message #477949] |
Mon, 17 November 2008 08:28 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Alexandre,
To be fair, there is a difference between MultiplicityElement::lowerValue
and MultiplicityElement::lower; former is effectively typed by a "wrapper"
type and so is nullable, whereas the latter is typed by a primitive. So,
while MultiplicityElement::lowerBound() won't return null (since it too is
typed by a primitive), MultiplicityElement::getLowerValue() will - that's
why the OCL expression you mentioned references
MultiplicityElement::lowerValue instead of MultiplicityElement::lower.
These "limitations" you mention, at least in the case of profiles, arise
from the mapping of UML concepts to EMOF/Ecore concepts and from the fact
that some things which are expressable in Ecore (like whether a feature's
value has been set) aren't expressable in UML. To support an "unset" state
for stereotype properties, simply apply the Ecore profile and set the
EAttribute::isUnsettable tag to 'true'...
Kenn
"Alexandre Torres" <alexandre.torres@gmail.com> wrote in message
news:a5c037f8b73afdc4d389f096a9566494$1@www.eclipse.org...
> Lets revive this thread.
> This is too another real problem, not being able to set primitive types as
> null, like Boolean. If you read the UML spec you going to see that several
> ocl rules are based upon nullable integer values like MultiplicityElement
> lower bound:
> From UML specification:
> lowerBound = if lowerValue->isEmpty() then 1 else
> lowerValue.integerValue() endif
>
> so, lowerbound will never be empty when using uml2. Divergences like that
> may seem small now, but in the long term make hard or impossible
> interoperate models between tools. And as pointed before, the lack of
> hability to say that some thing accept nulls, leaving the decision about
> the value assumed to default values or later check is important. For
> instance, I can use default values to simulate the "unset" state, but, if
> the default value changes, it's impossible to tell what situation the user
> choose the value and what the situation where the user left it unset. To
> make it worse, the unset state works very well for String and not
> primitive types.
> But if I add an wrapper as Ed proposed, this will make my model "strange".
> Someone looking at my model will say "why you did it?" and I will have to
> answer "becouse my uml toolkit has this limitation". All ocl rules will
> had to be written to use wrappers, and will look alien to uml purists, and
> bigger too.
> Well i'm disappointed with this limitation. Someone that works with uml
> should not be bound with those EMF problems (UML-MOF problems are already
> a lot).
> In the end I can't find any OMG uml tool that really implements the
> specification with a good support for profile creation like eclipse's
> implementation - what is only possible becouse of EMF's maturity. But EMF
> will not evolve ?
>
> Thanks
>
|
|
|
Goto Forum:
Current Time: Thu Sep 26 19:25:07 GMT 2024
Powered by FUDForum. Page generated in 0.06402 seconds |
] 
Search
Help
Register
Login
Home
