Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization
[EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization [message #995538] Sun, 30 December 2012 06:45 Go to next message
Alex Panchenko is currently offline Alex Panchenko
Messages: 342
Registered: July 2009
Senior Member
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26013
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
Re: [EMF] EcoreUtil.EqualityHelper.haveEqualFeature() optimization [message #997228 is a reply to message #995550] Fri, 04 January 2013 09:09 Go to previous messageGo to next message
Alex Panchenko is currently offline 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 10:15 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26013
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
>>
>
Previous Topic:EMF RCP from e3 to e4
Next Topic:e(fx)clipse 0.8.0 - EMF-Edit support for JavaFX
Goto Forum:
  


Current Time: Thu Aug 28 11:17:36 EDT 2014

Powered by FUDForum. Page generated in 0.02831 seconds