Home » Modeling » EMF » [EMF] Dynamic eGet for unsettable attributes
| [EMF] Dynamic eGet for unsettable attributes [message #522692] |
Tue, 23 March 2010 15:51  |
 Alan McMorran
Messages: 55
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
----------------1451798806366411897
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi,
I've been trying to debug (what I consider) some unexpected behaviour
when using eGet on EAttributes that have an EDataType which has an
primitive instance class type, but are unsettable.
I've been using the Modisco editor with my data and it uses reflective
providers to populate the Property View for an object. My issue is
that a few of my classes have a large number of attributes that have an
EDataType whose instance class is a primitive type (float, boolean, int
mainly). Since they are unset I would expect the property view to show
them as being empty (as it does for Strings), but instead it is
populated with the default 0 value.
On doing some digging through the code I found that in the
InternalSettingDelegateSingleData class within the
EStructuralFeatureImpl class the dynamicGet() method has this code:
Object result = settings.dynamicGet(index);
if (result == null)
{
return this.defaultValue;
}
else if (result == NIL)
{
return null;
}
else
{
return result;
}
Tracing the calls for these unset primitive type attributes the result
from dynamicGet(index) is null, as I would expect, but the dynamicGet
method doesn't return this, it instead returns the defaultValue (which
cannot be null for a primitive type) ignoring whether the attribute is
unsettable or not.
Is this a bug or is this the expected behaviour and thus something I
should work around?
Thanks for any help :-)
Alan
----------------1451798806366411897
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1038.25">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Helvetica; min-height: 14.0px}
p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Helvetica}
p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco}
p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #1100d0}
span.s1 {color: #a2006a}
span.s2 {color: #000000}
span.s3 {color: #1100d0}
</style>
</head>
<body>
<p class="p1">Hi,</p>
<p class="p2"><br></p>
<p class="p3">I've been trying to debug (what I consider) some unexpected behaviour when using eGet on EAttributes that have an EDataType which has an primitive instance class type, but are unsettable.</p>
<p class="p2"><br></p>
<p class="p3">I've been using the Modisco editor with my data and it uses reflective providers to populate the Property View for an object.<span class="Apple-converted-space">
|
|
|
| Re: [EMF] Dynamic eGet for unsettable attributes [message #522785 is a reply to message #522692] |
Tue, 23 March 2010 22:13  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070602090400060201070408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Alan,
Features of primitive type simply cannot ever be null because null is
not a primitive value. In a generated class there'd be a field "int
foo" and eGet would do return foo, which would have to be a non-null
value. So a dynamic value simulates that same expected result.
Alan McMorran wrote:
>
> Hi,
>
>
> I've been trying to debug (what I consider) some unexpected behaviour
> when using eGet on EAttributes that have an EDataType which has an
> primitive instance class type, but are unsettable.
>
>
> I've been using the Modisco editor with my data and it uses reflective
> providers to populate the Property View for an object. My issue is
> that a few of my classes have a large number of attributes that have
> an EDataType whose instance class is a primitive type (float, boolean,
> int mainly). Since they are unset I would expect the property view to
> show them as being empty (as it does for Strings), but instead it is
> populated with the default 0 value.
>
>
> On doing some digging through the code I found that in the
> InternalSettingDelegateSingleData class within the
> EStructuralFeatureImpl class the dynamicGet() method has this code:
>
>
> Object result = settings.dynamicGet(index);
>
> if (result == null)
>
> {
>
> return this.defaultValue;
>
> }
>
> else if (result == NIL)
>
> {
>
> return null;
>
> }
>
> else
>
> {
>
> return result;
>
> }
>
>
> Tracing the calls for these unset primitive type attributes the result
> from dynamicGet(index) is null, as I would expect, but the dynamicGet
> method doesn't return this, it instead returns the defaultValue (which
> cannot be null for a primitive type) ignoring whether the attribute is
> unsettable or not.
>
>
> Is this a bug or is this the expected behaviour and thus something I
> should work around?
>
>
> Thanks for any help :-)
>
>
> Alan
>
>
--------------070602090400060201070408
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">
Alan,<br>
<br>
Features of primitive type simply cannot ever be null because null is
not a primitive value. In a generated class there'd be a field "int
foo" and eGet would do return foo, which would have to be a non-null
value. So a dynamic value simulates that same expected result.<br>
<br>
<br>
Alan McMorran wrote:
<blockquote cite="mid:hoao1o$34r$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1038.25">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Helvetica; min-height: 14.0px}
p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 14.0px; font: 12.0px Helvetica}
p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco}
p.p5 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Monaco; color: #1100d0}
span.s1 {color: #a2006a}
span.s2 {color: #000000}
span.s3 {color: #1100d0}
</style>
<p class="p1">Hi,</p>
<p class="p2"><br>
</p>
<p class="p3">I've been trying to debug (what I consider) some
unexpected behaviour when using eGet on EAttributes that have an
EDataType which has an primitive instance class type, but are
unsettable.</p>
<p class="p2"><br>
</p>
<p class="p3">I've been using the Modisco editor with my data and it
uses reflective providers to populate the Property View for an object.<span
class="Apple-converted-space"> </span>My issue is that a few of my
classes have a large number of attributes that have an EDataType whose
instance class is a primitive type (float, boolean, int mainly).<span
class="Apple-converted-space"> </span>Since they are unset I would
expect the property view to show them as being empty (as it does for
Strings), but instead it is populated with the default 0 value.</p>
<p class="p2"><br>
</p>
<p class="p3">On doing some digging through the code I found that in
the InternalSettingDelegateSingleData class within the
EStructuralFeatureImpl class the dynamicGet() method has this code:</p>
<p class="p2"><br>
</p>
<p class="p4">Object result = settings.dynamicGet(index);</p>
<p class="p4"><span class="Apple-converted-space"> </span><span
class="s1">if</span> (result == <span class="s1">null</span>)</p>
<p class="p4"><span class="Apple-converted-space"> </span>{</p>
<p class="p5"><span class="s2"><span class="Apple-converted-space">
</span></span><span class="s1">return</span><span class="s2"> </span><span
class="s1">this</span><span class="s2">.</span>defaultValue<span
class="s2">;</span></p>
<p class="p4"><span class="Apple-converted-space"> </span>}</p>
<p class="p4"><span class="Apple-converted-space"> </span><span
class="s1">else</span> <span class="s1">if</span> (result == <span
class="s3">NIL</span>)</p>
<p class="p4"><span class="Apple-converted-space"> </span>{</p>
<p class="p4"><span class="Apple-converted-space"> </span><span
class="s1">return</span> <span class="s1">null</span>;</p>
<p class="p4"><span class="Apple-converted-space"> </span>}</p>
<p class="p4"><span class="Apple-converted-space"> </span><span
class="s1">else</span></p>
<p class="p4"><span class="Apple-converted-space"> </span>{</p>
<p class="p4"><span class="Apple-converted-space"> </span><span
class="s1">return</span> result;</p>
<p class="p4"><span class="Apple-converted-space"> </span>}</p>
<p class="p2"><br>
</p>
<p class="p3">Tracing the calls for these unset primitive type
attributes the result from dynamicGet(index) is null, as I would
expect, but the dynamicGet method doesn't return this, it instead
returns the defaultValue (which cannot be null for a primitive type)
ignoring whether the attribute is unsettable or not.</p>
<p class="p2"><br>
</p>
<p class="p3">Is this a bug or is this the expected behaviour and
thus something I should work around?</p>
<p class="p2"><br>
</p>
<p class="p3">Thanks for any help :-)</p>
<p class="p2"><br>
</p>
<p class="p3">Alan</p>
<p class="p2"><br>
</p>
</blockquote>
</body>
</html>
--------------070602090400060201070408--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] Dynamic eGet for unsettable attributes [message #522794 is a reply to message #522785] |
Tue, 23 March 2010 22:40 |
Alan McMorran
Messages: 55
Registered: July 2009 |
Member |
|
|
Ok, that makes sense :-) My issue is therefore in the presentation of
the value, not the returned value itself, so I'll need to work out how
I can get the Properties view to reflect the isSet status of a feature
in an object...
Thanks for the explanation, I appreciate the time you spend answering
questions on the newsgroup, your replies on all mannger of topics have
helped me out immensely!
Alan
On 2010-03-23 22:13:34 +0000, Ed Merks said:
> Alan,
>
> Features of primitive type simply cannot ever be null because null is
> not a primitive value. In a generated class there'd be a field "int
> foo" and eGet would do return foo, which would have to be a non-null
> value. So a dynamic value simulates that same expected result.
>
>
> Alan McMorran wrote:
> Hi,
>
> I've been trying to debug (what I consider) some unexpected behaviour
> when using eGet on EAttributes that have an EDataType which has an
> primitive instance class type, but are unsettable.
>
> I've been using the Modisco editor with my data and it uses reflective
> providers to populate the Property View for an object. My issue is
> that a few of my classes have a large number of attributes that have an
> EDataType whose instance class is a primitive type (float, boolean, int
> mainly). Since they are unset I would expect the property view to show
> them as being empty (as it does for Strings), but instead it is
> populated with the default 0 value.
>
> On doing some digging through the code I found that in the
> InternalSettingDelegateSingleData class within the
> EStructuralFeatureImpl class the dynamicGet() method has this code:
>
> Object result = settings.dynamicGet(index);
> if (result == null)
> {
> return this.defaultValue;
> }
> else if (result == NIL)
> {
> return null;
> }
> else
> {
> return result;
> }
>
> Tracing the calls for these unset primitive type attributes the result
> from dynamicGet(index) is null, as I would expect, but the dynamicGet
> method doesn't return this, it instead returns the defaultValue (which
> cannot be null for a primitive type) ignoring whether the attribute is
> unsettable or not.
>
> Is this a bug or is this the expected behaviour and thus something I
> should work around?
>
> Thanks for any help :-)
>
> Alan
|
|
|
Goto Forum:
Current Time: Sat Apr 27 01:06:27 GMT 2024
Powered by FUDForum. Page generated in 0.03709 seconds |
] 
Search
Help
Register
Login
Home
