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 11:45 Go to next message
Alex Panchenko is currently offline Alex PanchenkoFriend
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 12:39 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26289
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 14:09 Go to previous messageGo to next message
Alex Panchenko is currently offline Alex PanchenkoFriend
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26289
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: Mon Dec 22 14:14:52 GMT 2014

Powered by FUDForum. Page generated in 0.01776 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software