Home » Modeling » EMF » [EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization
| [EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization [message #995538] |
Sun, 30 December 2012 06:45  |
Eclipse User |
|
|
|
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.
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?
Should I file a bug?
Regards,
Alex
|
|
|
| Re: [EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization [message #995550 is a reply to message #995538] |
Sun, 30 December 2012 07:39  |
| Eclipse User |
|
|
|
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 #997228 is a reply to message #995550] |
Fri, 04 January 2013 09:09 |
| Eclipse User |
|
|
|
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 10:15 |
| Eclipse User |
|
|
|
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
>>
>
|
|
|
Goto Forum:
Current Time: Wed Jul 23 08:35:58 EDT 2025
Powered by FUDForum. Page generated in 0.04948 seconds |
Home