Home » Modeling » EMF » unsettable and required
|
| Re: unsettable and required [message #418057 is a reply to message #418053] |
Fri, 04 April 2008 11:01   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070506070306000809050306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Martin,
Comments below.
Martin Taal wrote:
> Hi Ed,
> I am revisiting an old topic from many years back just to be sure:
> unsettable and required (minOccurs=1)
Oddly this was a topic that Dave brought up recently as well, resulting
in 222754 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=222754> which
I've was prototyping last weekend.
>
> Unsettable makes it possible for EMF to determine for a feature with a
> default value if it has been set or not, so that when the value of the
> feature == the default value that EMF can determine if the feature has
> been explicitly set or defaulted.
>
> Is this a correct statement?
Yes. Unsettable adds an additional state to the feature's possible set
of states. A non-unsettable feature (aren't double negatives great!)
can take on all the values in the value space and one of those values
will be the feature's default value; even a feature without a default
has the "intrinsic default" of its type as an implicit default. For
most types, this is intrinsic default is just null, but for primitives,
this type it is 0/0.0; an EEnum is treated like a primitive and hence
the first EEnumLiteral is considered the intrinsic default. So, in
general, a non-unsettable feature is considered set (eIsSet is true) if
the value is different from the implicit/explicit default. Note that
for isMany features, the empty list is the implicit default (and
non-empty list defaults are not supported). So what an unsettable
features adds to the mix is effectively like adding one additional value
to the value space, or one additional state. This special value (it
isn't really an additional value since you can't extend the value space)
effectively splits the default value into two values, one representing
the state when the feature is not set and hence implicitly has the
default value, and the other representing the state when the feature is
explicitly set to the default value. A good way to think of the
distinction is to consider an attribute x with default "" and consider
the distinction between <element x=""/> verses <element/>.
> So then a required efeature (minoccurs=1) can still be unsettable?
Yes, unsettable is orthogonal lowerBound.
--------------070506070306000809050306
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">
Martin,<br>
<br>
Comments below.<br>
<br>
Martin Taal wrote:
<blockquote cite="mid:ft4ugl$4op$1@build.eclipse.org" type="cite">Hi
Ed,
<br>
I am revisiting an old topic from many years back just to be sure:
unsettable and required (minOccurs=1)
<br>
</blockquote>
Oddly this was a topic that Dave brought up recently as well, resulting
in <a name="b222754"
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=222754">222754</a>
which I've was prototyping last weekend.<br>
<blockquote cite="mid:ft4ugl$4op$1@build.eclipse.org" type="cite"><br>
Unsettable makes it possible for EMF to determine for a feature with a
default value if it has been set or not, so that when the value of the
feature == the default value that EMF can determine if the feature has
been explicitly set or defaulted.
<br>
<br>
Is this a correct statement?
<br>
</blockquote>
Yes. Unsettable adds an additional state to the feature's possible set
of states. A non-unsettable feature (aren't double negatives great!)
can take on all the values in the value space and one of those values
will be the feature's default value; even a feature without a default
has the "intrinsic default" of its type as an implicit default. For
most types, this is intrinsic default is just null, but for primitives,
this type it is 0/0.0; an EEnum is treated like a primitive and hence
the first EEnumLiteral is considered the intrinsic default. So, in
general, a non-unsettable feature is considered set (eIsSet is true) if
the value is different from the implicit/explicit default. Note that
for isMany features, the empty list is the implicit default (and
non-empty list defaults are not supported). So what an unsettable
features adds to the mix is effectively like adding one additional
value to the value space, or one additional state. This special value
(it isn't really an additional value since you can't extend the value
space) effectively splits the default value into two values, one
representing the state when the feature is not set and hence implicitly
has the default value, and the other representing the state when the
feature is explicitly set to the default value. A good way to think of
the distinction is to consider an attribute x with default "" and
consider the distinction between <element x=""/> verses
<element/>. <br>
<br>
<blockquote cite="mid:ft4ugl$4op$1@build.eclipse.org" type="cite">So
then a required efeature (minoccurs=1) can still be unsettable?
<br>
</blockquote>
Yes, unsettable is orthogonal lowerBound. <br>
<br>
</body>
</html>
--------------070506070306000809050306--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: unsettable and required [message #418060 is a reply to message #418057] |
Fri, 04 April 2008 11:16 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Thanks, the topic mentioned in the bugzilla is also something which I encountered while making the
Teneo Editor tutorial. So if this can be done in a more intuitive way then that would be great.
gr. Martin
Ed Merks wrote:
> Martin,
>
> Comments below.
>
> Martin Taal wrote:
>> Hi Ed,
>> I am revisiting an old topic from many years back just to be sure:
>> unsettable and required (minOccurs=1)
> Oddly this was a topic that Dave brought up recently as well, resulting
> in 222754 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=222754> which
> I've was prototyping last weekend.
>>
>> Unsettable makes it possible for EMF to determine for a feature with a
>> default value if it has been set or not, so that when the value of the
>> feature == the default value that EMF can determine if the feature has
>> been explicitly set or defaulted.
>>
>> Is this a correct statement?
> Yes. Unsettable adds an additional state to the feature's possible set
> of states. A non-unsettable feature (aren't double negatives great!)
> can take on all the values in the value space and one of those values
> will be the feature's default value; even a feature without a default
> has the "intrinsic default" of its type as an implicit default. For
> most types, this is intrinsic default is just null, but for primitives,
> this type it is 0/0.0; an EEnum is treated like a primitive and hence
> the first EEnumLiteral is considered the intrinsic default. So, in
> general, a non-unsettable feature is considered set (eIsSet is true) if
> the value is different from the implicit/explicit default. Note that
> for isMany features, the empty list is the implicit default (and
> non-empty list defaults are not supported). So what an unsettable
> features adds to the mix is effectively like adding one additional value
> to the value space, or one additional state. This special value (it
> isn't really an additional value since you can't extend the value space)
> effectively splits the default value into two values, one representing
> the state when the feature is not set and hence implicitly has the
> default value, and the other representing the state when the feature is
> explicitly set to the default value. A good way to think of the
> distinction is to consider an attribute x with default "" and consider
> the distinction between <element x=""/> verses <element/>.
>
>> So then a required efeature (minoccurs=1) can still be unsettable?
> Yes, unsettable is orthogonal lowerBound.
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
Goto Forum:
Current Time: Fri Apr 26 12:24:26 GMT 2024
Powered by FUDForum. Page generated in 0.03364 seconds |
] 
Search
Help
Register
Login
Home
