Home » Modeling » EMF » [EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization
|
| Re: [EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization [message #995550 is a reply to message #995538] |
Sun, 30 December 2012 12:39   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Alex,
Comments below.
On 30/12/2012 12:45 PM, Alex Panchenko wrote:
> Hello,
>
> I have a question regarding the implementation of
> org.eclipse.emf.ecore.util.EcoreUtil.EqualityHelper.haveEqualFeature(EObject,
> EObject, EStructuralFeature) method.
>
> It seems to me, that if both features are not set, then
> function can return true without comparing the actual values.
Yes it would be odd that they should have different values if they're
not set. Such a case is possible with Ecore which has features that are
effectively mutually derived, e.g.,
EClass.getESuperTypes/getEGenericSuperTypes, but even in that case,
either the super types or the generic super types (currently both but
with your suggestion only one of them) will still be compared to yield
the correct result.
> For simple types that's not a big deal, but it makes a difference for
> collections, as they become instantiated during the read.
>
> Is there any specific reason for the current implementation?
No, I think your suggestion is a good one.
> Should I file a bug?
Please do!
>
> Regards,
> Alex
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization [message #997228 is a reply to message #995550] |
Fri, 04 January 2013 14:09 |
Alex Panchenko
Messages: 342
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
Thanks for the comments, I filed a bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=397444
btw, where can I find the EMF formatter settings, mentioned in
http://wiki.eclipse.org/EMF/Setting_up_a_development_environment?
I failed to find that file in the git repository.
Regards,
Alex
On 12/30/2012 07:39 PM, Ed Merks wrote:
> Alex,
>
> Comments below.
>
> On 30/12/2012 12:45 PM, Alex Panchenko wrote:
>> Hello,
>>
>> I have a question regarding the implementation of
>> org.eclipse.emf.ecore.util.EcoreUtil.EqualityHelper.haveEqualFeature(EObject,
>> EObject, EStructuralFeature) method.
>>
>> It seems to me, that if both features are not set, then
>> function can return true without comparing the actual values.
> Yes it would be odd that they should have different values if they're
> not set. Such a case is possible with Ecore which has features that are
> effectively mutually derived, e.g.,
> EClass.getESuperTypes/getEGenericSuperTypes, but even in that case,
> either the super types or the generic super types (currently both but
> with your suggestion only one of them) will still be compared to yield
> the correct result.
>> For simple types that's not a big deal, but it makes a difference for
>> collections, as they become instantiated during the read.
>>
>> Is there any specific reason for the current implementation?
> No, I think your suggestion is a good one.
>> Should I file a bug?
> Please do!
>>
>> Regards,
>> Alex
>
|
|
|
| Re: [EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization [message #997645 is a reply to message #997228] |
Fri, 04 January 2013 15:15 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Alex,
The wiki still talks about CVS so that's out of date too. :-(
We (I) don't generally format any of our code; it's all hand formatted...
On 04/01/2013 3:09 PM, Alex Panchenko wrote:
> Hi Ed,
>
> Thanks for the comments, I filed a bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=397444
>
> btw, where can I find the EMF formatter settings, mentioned in
> http://wiki.eclipse.org/EMF/Setting_up_a_development_environment?
> I failed to find that file in the git repository.
>
> Regards,
> Alex
>
>
> On 12/30/2012 07:39 PM, Ed Merks wrote:
>> Alex,
>>
>> Comments below.
>>
>> On 30/12/2012 12:45 PM, Alex Panchenko wrote:
>>> Hello,
>>>
>>> I have a question regarding the implementation of
>>> org.eclipse.emf.ecore.util.EcoreUtil.EqualityHelper.haveEqualFeature(EObject,
>>>
>>> EObject, EStructuralFeature) method.
>>>
>>> It seems to me, that if both features are not set, then
>>> function can return true without comparing the actual values.
>> Yes it would be odd that they should have different values if they're
>> not set. Such a case is possible with Ecore which has features that are
>> effectively mutually derived, e.g.,
>> EClass.getESuperTypes/getEGenericSuperTypes, but even in that case,
>> either the super types or the generic super types (currently both but
>> with your suggestion only one of them) will still be compared to yield
>> the correct result.
>>> For simple types that's not a big deal, but it makes a difference for
>>> collections, as they become instantiated during the read.
>>>
>>> Is there any specific reason for the current implementation?
>> No, I think your suggestion is a good one.
>>> Should I file a bug?
>> Please do!
>>>
>>> Regards,
>>> Alex
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 17:07:46 GMT 2024
Powered by FUDForum. Page generated in 0.03375 seconds |
] 
Search
Help
Register
Login
Home
