Home » Modeling » EMF » eIsSet Do not behave the same things between EStoreEObjectImpl and EObjectImpl.
| |
| Re: eIsSet Do not behave the same things between EStoreEObjectImpl and EObjectImpl. [message #426384 is a reply to message #426383] |
Thu, 01 January 2009 21:19   |
 Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Simon,
>
> Comments below.
>
> Simon McDuff wrote:
>> In the following example I have a mismatch of behavior.
>>
>>
>> ClassA
>> |___featureA: String defaultvalue = "Ottawa"
>>
>>
>>
>> 1- instanceOfA.eGet(featureA) == "Ottawa"; (this is fine)
>>
>> 2- instanceOfA.eSet(featureA, null);
>>
>> 3- instanceOfA.eIsSet(featureA); Should return true.
>>
>> 4- instanceOfA.eGet(featureA); Should return null.
>>
>> The instructions number 3 have a mismatch behavior depending of which
>> implementation I used.
>>
>> If I used EObjectImpl... it will works as expected.
>> If I used EStoreEObjectImpl it will return me
>>
>> 3- instanceOfA.eIsSet(featureA); Should return FALSE.
>>
>> 4- instanceOfA.eGet(featureA); Should return "Ottawa".
>>
>>
>> In EStoreEObject.dynamicSet we are doing the following:
>>
>> eStore().set(this, eStructuralFeature,
>> InternalEObject.EStore.NO_INDEX, value == NIL ? null : value);
>>
>> NIL means null when defaultValue != null.
> NIL always mean explicitly set to null as opposed to not initialized and
> hence having the default value; at least that's how it's supposed to
> work...
Yes
>>
>> So, putting the value at null means putting back the default value
>> since eGet will return the defaultValue when value == null.
>>
>> My question: Is it a bug ?
> Not sure what "it" is though; later eStore().get() is called again and
> it should return null again, not the default value. The store is
> responsible for ensuring that setting a value to null leaves it as null...
EStore will return null!! But the problem is in the setting delegate :
public Object dynamicGet(InternalEObject owner,
EStructuralFeature.Internal.DynamicValueHolder settings, int index,
boolean resolve, boolean coreType)
{
Object result = settings.dynamicGet(index);
if (result == null)
{
return this.defaultValue; <<<<<<<<<<<<<<
}
else if (result == NIL)
{
return null;
}
else
{
return result;
}
}
When application uses EStoreEobjectImpl putting a feature at null always
mean putting the value at defaultValue and this is the problem. Isn't?
>>
>> Simon
>>
>>
|
|
|
| Re: eIsSet Do not behave the same things between EStoreEObjectImpl and EObjectImpl. [message #426385 is a reply to message #426384] |
Thu, 01 January 2009 23:33 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Simon,
It sure sounds like a problem. :-P I'm not sure the solution. It
sounds like the store itself needs to know about NIL or that we needed
to be smarter somewhere else...
Simon McDuff wrote:
> Ed Merks wrote:
>> Simon,
>>
>> Comments below.
>>
>> Simon McDuff wrote:
>>> In the following example I have a mismatch of behavior.
>>>
>>>
>>> ClassA
>>> |___featureA: String defaultvalue = "Ottawa"
>>>
>>>
>>>
>>> 1- instanceOfA.eGet(featureA) == "Ottawa"; (this is fine)
>>>
>>> 2- instanceOfA.eSet(featureA, null);
>>>
>>> 3- instanceOfA.eIsSet(featureA); Should return true.
>>>
>>> 4- instanceOfA.eGet(featureA); Should return null.
>>>
>>> The instructions number 3 have a mismatch behavior depending of
>>> which implementation I used.
>>>
>>> If I used EObjectImpl... it will works as expected.
>>> If I used EStoreEObjectImpl it will return me
>>>
>>> 3- instanceOfA.eIsSet(featureA); Should return FALSE.
>>>
>>> 4- instanceOfA.eGet(featureA); Should return "Ottawa".
>>>
>>>
>>> In EStoreEObject.dynamicSet we are doing the following:
>>>
>>> eStore().set(this, eStructuralFeature,
>>> InternalEObject.EStore.NO_INDEX, value == NIL ? null : value);
>>>
>>> NIL means null when defaultValue != null.
>> NIL always mean explicitly set to null as opposed to not initialized
>> and hence having the default value; at least that's how it's supposed
>> to work...
> Yes
>>>
>>> So, putting the value at null means putting back the default value
>>> since eGet will return the defaultValue when value == null.
>>>
>>> My question: Is it a bug ?
>> Not sure what "it" is though; later eStore().get() is called again
>> and it should return null again, not the default value. The store is
>> responsible for ensuring that setting a value to null leaves it as
>> null...
>
> EStore will return null!! But the problem is in the setting delegate :
>
> public Object dynamicGet(InternalEObject owner,
> EStructuralFeature.Internal.DynamicValueHolder settings, int index,
> boolean resolve, boolean coreType)
> {
> Object result = settings.dynamicGet(index);
> if (result == null)
> {
> return this.defaultValue; <<<<<<<<<<<<<<
> }
> else if (result == NIL)
> {
> return null;
> }
> else
> {
> return result;
> }
> }
>
>
> When application uses EStoreEobjectImpl putting a feature at null
> always mean putting the value at defaultValue and this is the problem.
> Isn't?
>
>
>
>>>
>>> Simon
>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: eIsSet Do not behave the same things between EStoreEObjectImpl and EObjectImpl. [message #426386 is a reply to message #426385] |
Thu, 01 January 2009 23:43 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
It is what I thought as well.
SettingDelegate shouldn't convert NIL to NULL at any place.
I will create a bugzilla!! ok ?
It will help me a lot for the following bugzilla that we have :
258933: CDORevisionImpl.eIsSet() works incorrectly
https://bugs.eclipse.org/bugs/show_bug.cgi?id=258933
Simon
Ed Merks wrote:
> Simon,
>
> It sure sounds like a problem. :-P I'm not sure the solution. It
> sounds like the store itself needs to know about NIL or that we needed
> to be smarter somewhere else...
>
>
> Simon McDuff wrote:
>> Ed Merks wrote:
>>> Simon,
>>>
>>> Comments below.
>>>
>>> Simon McDuff wrote:
>>>> In the following example I have a mismatch of behavior.
>>>>
>>>>
>>>> ClassA
>>>> |___featureA: String defaultvalue = "Ottawa"
>>>>
>>>>
>>>>
>>>> 1- instanceOfA.eGet(featureA) == "Ottawa"; (this is fine)
>>>>
>>>> 2- instanceOfA.eSet(featureA, null);
>>>>
>>>> 3- instanceOfA.eIsSet(featureA); Should return true.
>>>>
>>>> 4- instanceOfA.eGet(featureA); Should return null.
>>>>
>>>> The instructions number 3 have a mismatch behavior depending of
>>>> which implementation I used.
>>>>
>>>> If I used EObjectImpl... it will works as expected.
>>>> If I used EStoreEObjectImpl it will return me
>>>>
>>>> 3- instanceOfA.eIsSet(featureA); Should return FALSE.
>>>>
>>>> 4- instanceOfA.eGet(featureA); Should return "Ottawa".
>>>>
>>>>
>>>> In EStoreEObject.dynamicSet we are doing the following:
>>>>
>>>> eStore().set(this, eStructuralFeature,
>>>> InternalEObject.EStore.NO_INDEX, value == NIL ? null : value);
>>>>
>>>> NIL means null when defaultValue != null.
>>> NIL always mean explicitly set to null as opposed to not initialized
>>> and hence having the default value; at least that's how it's supposed
>>> to work...
>> Yes
>>>>
>>>> So, putting the value at null means putting back the default value
>>>> since eGet will return the defaultValue when value == null.
>>>>
>>>> My question: Is it a bug ?
>>> Not sure what "it" is though; later eStore().get() is called again
>>> and it should return null again, not the default value. The store is
>>> responsible for ensuring that setting a value to null leaves it as
>>> null...
>>
>> EStore will return null!! But the problem is in the setting delegate :
>>
>> public Object dynamicGet(InternalEObject owner,
>> EStructuralFeature.Internal.DynamicValueHolder settings, int index,
>> boolean resolve, boolean coreType)
>> {
>> Object result = settings.dynamicGet(index);
>> if (result == null)
>> {
>> return this.defaultValue; <<<<<<<<<<<<<<
>> }
>> else if (result == NIL)
>> {
>> return null;
>> }
>> else
>> {
>> return result;
>> }
>> }
>>
>>
>> When application uses EStoreEobjectImpl putting a feature at null
>> always mean putting the value at defaultValue and this is the problem.
>> Isn't?
>>
>>
>>
>>>>
>>>> Simon
>>>>
>>>>
|
|
|
| Re: eIsSet Do not behave the same things between EStoreEObjectImpl and EObjectImpl. [message #426387 is a reply to message #426386] |
Fri, 02 January 2009 01:53 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Simon,
The problem is that it should since it's null that it uses to represent
"unset". It's the client that should never see NIL... Which means the
store probably needs to be aware of it as well as produce it.
Yes, please open a bugzilla for the issue...
Simon McDuff wrote:
> It is what I thought as well.
>
> SettingDelegate shouldn't convert NIL to NULL at any place.
>
> I will create a bugzilla!! ok ?
>
> It will help me a lot for the following bugzilla that we have :
>
> 258933: CDORevisionImpl.eIsSet() works incorrectly
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=258933
>
> Simon
>
> Ed Merks wrote:
>> Simon,
>>
>> It sure sounds like a problem. :-P I'm not sure the solution. It
>> sounds like the store itself needs to know about NIL or that we
>> needed to be smarter somewhere else...
>>
>>
>> Simon McDuff wrote:
>>> Ed Merks wrote:
>>>> Simon,
>>>>
>>>> Comments below.
>>>>
>>>> Simon McDuff wrote:
>>>>> In the following example I have a mismatch of behavior.
>>>>>
>>>>>
>>>>> ClassA
>>>>> |___featureA: String defaultvalue = "Ottawa"
>>>>>
>>>>>
>>>>>
>>>>> 1- instanceOfA.eGet(featureA) == "Ottawa"; (this is fine)
>>>>>
>>>>> 2- instanceOfA.eSet(featureA, null);
>>>>>
>>>>> 3- instanceOfA.eIsSet(featureA); Should return true.
>>>>>
>>>>> 4- instanceOfA.eGet(featureA); Should return null.
>>>>>
>>>>> The instructions number 3 have a mismatch behavior depending of
>>>>> which implementation I used.
>>>>>
>>>>> If I used EObjectImpl... it will works as expected.
>>>>> If I used EStoreEObjectImpl it will return me
>>>>>
>>>>> 3- instanceOfA.eIsSet(featureA); Should return FALSE.
>>>>>
>>>>> 4- instanceOfA.eGet(featureA); Should return "Ottawa".
>>>>>
>>>>>
>>>>> In EStoreEObject.dynamicSet we are doing the following:
>>>>>
>>>>> eStore().set(this, eStructuralFeature,
>>>>> InternalEObject.EStore.NO_INDEX, value == NIL ? null : value);
>>>>>
>>>>> NIL means null when defaultValue != null.
>>>> NIL always mean explicitly set to null as opposed to not
>>>> initialized and hence having the default value; at least that's how
>>>> it's supposed to work...
>>> Yes
>>>>>
>>>>> So, putting the value at null means putting back the default value
>>>>> since eGet will return the defaultValue when value == null.
>>>>>
>>>>> My question: Is it a bug ?
>>>> Not sure what "it" is though; later eStore().get() is called again
>>>> and it should return null again, not the default value. The store
>>>> is responsible for ensuring that setting a value to null leaves it
>>>> as null...
>>>
>>> EStore will return null!! But the problem is in the setting delegate :
>>>
>>> public Object dynamicGet(InternalEObject owner,
>>> EStructuralFeature.Internal.DynamicValueHolder settings, int index,
>>> boolean resolve, boolean coreType)
>>> {
>>> Object result = settings.dynamicGet(index);
>>> if (result == null)
>>> {
>>> return this.defaultValue; <<<<<<<<<<<<<<
>>> }
>>> else if (result == NIL)
>>> {
>>> return null;
>>> }
>>> else
>>> {
>>> return result;
>>> }
>>> }
>>>
>>>
>>> When application uses EStoreEobjectImpl putting a feature at null
>>> always mean putting the value at defaultValue and this is the
>>> problem. Isn't?
>>>
>>>
>>>
>>>>>
>>>>> Simon
>>>>>
>>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: eIsSet Do not behave the same things between EStoreEObjectImpl and EObjectImpl. [message #426389 is a reply to message #426387] |
Fri, 02 January 2009 03:51 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Simon,
>
> The problem is that it should since it's null that it uses to represent
> "unset". It's the client that should never see NIL... Which means the
> store probably needs to be aware of it as well as produce it.
I think we didn't understand each other...
I mentionned that Setting delegate convert NIL to NULL(by calling
dynamicSet)... in the case where it delegate the call to the Store not
the client.. :-)
eStore().set(this, eStructuralFeature,
InternalEObject.EStore.NO_INDEX, value == NIL ? null : value);
Here the bugzilla :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=259855
Thank you!
>
> Yes, please open a bugzilla for the issue...
>
>
> Simon McDuff wrote:
>> It is what I thought as well.
>>
>> SettingDelegate shouldn't convert NIL to NULL at any place.
>>
>> I will create a bugzilla!! ok ?
>>
>> It will help me a lot for the following bugzilla that we have :
>>
>> 258933: CDORevisionImpl.eIsSet() works incorrectly
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=258933
>>
>> Simon
>>
>> Ed Merks wrote:
>>> Simon,
>>>
>>> It sure sounds like a problem. :-P I'm not sure the solution. It
>>> sounds like the store itself needs to know about NIL or that we
>>> needed to be smarter somewhere else...
>>>
>>>
>>> Simon McDuff wrote:
>>>> Ed Merks wrote:
>>>>> Simon,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Simon McDuff wrote:
>>>>>> In the following example I have a mismatch of behavior.
>>>>>>
>>>>>>
>>>>>> ClassA
>>>>>> |___featureA: String defaultvalue = "Ottawa"
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1- instanceOfA.eGet(featureA) == "Ottawa"; (this is fine)
>>>>>>
>>>>>> 2- instanceOfA.eSet(featureA, null);
>>>>>>
>>>>>> 3- instanceOfA.eIsSet(featureA); Should return true.
>>>>>>
>>>>>> 4- instanceOfA.eGet(featureA); Should return null.
>>>>>>
>>>>>> The instructions number 3 have a mismatch behavior depending of
>>>>>> which implementation I used.
>>>>>>
>>>>>> If I used EObjectImpl... it will works as expected.
>>>>>> If I used EStoreEObjectImpl it will return me
>>>>>>
>>>>>> 3- instanceOfA.eIsSet(featureA); Should return FALSE.
>>>>>>
>>>>>> 4- instanceOfA.eGet(featureA); Should return "Ottawa".
>>>>>>
>>>>>>
>>>>>> In EStoreEObject.dynamicSet we are doing the following:
>>>>>>
>>>>>> eStore().set(this, eStructuralFeature,
>>>>>> InternalEObject.EStore.NO_INDEX, value == NIL ? null : value);
>>>>>>
>>>>>> NIL means null when defaultValue != null.
>>>>> NIL always mean explicitly set to null as opposed to not
>>>>> initialized and hence having the default value; at least that's how
>>>>> it's supposed to work...
>>>> Yes
>>>>>>
>>>>>> So, putting the value at null means putting back the default value
>>>>>> since eGet will return the defaultValue when value == null.
>>>>>>
>>>>>> My question: Is it a bug ?
>>>>> Not sure what "it" is though; later eStore().get() is called again
>>>>> and it should return null again, not the default value. The store
>>>>> is responsible for ensuring that setting a value to null leaves it
>>>>> as null...
>>>>
>>>> EStore will return null!! But the problem is in the setting delegate :
>>>>
>>>> public Object dynamicGet(InternalEObject owner,
>>>> EStructuralFeature.Internal.DynamicValueHolder settings, int index,
>>>> boolean resolve, boolean coreType)
>>>> {
>>>> Object result = settings.dynamicGet(index);
>>>> if (result == null)
>>>> {
>>>> return this.defaultValue; <<<<<<<<<<<<<<
>>>> }
>>>> else if (result == NIL)
>>>> {
>>>> return null;
>>>> }
>>>> else
>>>> {
>>>> return result;
>>>> }
>>>> }
>>>>
>>>>
>>>> When application uses EStoreEobjectImpl putting a feature at null
>>>> always mean putting the value at defaultValue and this is the
>>>> problem. Isn't?
>>>>
>>>>
>>>>
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:28:45 GMT 2024
Powered by FUDForum. Page generated in 0.03320 seconds |
] 
Search
Help
Register
Login
Home
