Eclipse Community Forums: EMF » Add duplicated elements to EList

Help

Home

Home » Modeling » EMF » Add duplicated elements to EList

Show: Today's Messages :: Show Polls :: Message Navigator

Add duplicated elements to EList [message #1449711]

Tue, 21 October 2014 18:55

Thomas Zwickl

Messages: 37
Registered: May 2014

Member

Hello,

I've today encountered that although I've set the flag Unique for a reference in the EMF model to false, that I still cannot add duplicated objects.
It's a one way reference where I want to add several objects, which can also be the same objects. The only thing that's interesting for me is the order the objects appear in the list. Does anyone know what's the reason why I cannot add duplicated objects, despite the fact that I deactivated uniqueness?

I have already searched for the problem in the internet and encountered the following very old bug report, which still seems to be active:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325

Any ideas if this bug has already been resolved in one of the versions or if anyone is working on solving this problem?
Any help or pointers would be appreciated.

Report message to a moderator

Re: Add duplicated elements to EList [message #1450114 is a reply to message #1449711]

Wed, 22 October 2014 05:27

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Thomas,

Comments below.

On 21/10/2014 8:55 PM, Thomas Zwickl wrote:
> Hello,
>
> I've today encountered that although I've set the flag Unique for a
> reference in the EMF model to false, that I still cannot add
> duplicated objects. It's a one way reference where I want to add
> several objects, which can also be the same objects. The only thing
> that's interesting for me is the order the objects appear in the list.
> Does anyone know what's the reason why I cannot add duplicated
> objects, despite the fact that I deactivated uniqueness?
>
> I have already searched for the problem in the internet and
> encountered the following very old bug report, which still seems to be
> active:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325
Yes, it's an old issue. (Strange that I wasn't on the CC list.)
>
> Any ideas if this bug has already been resolved in one of the versions
> or if anyone is working on solving this problem?
No, not really.
> Any help or pointers would be appreciated.
It's clear from the implementation that the limitation is intentional.
As mentioned in there, the problem is that downstream assumptions in the
rest of the framework count on this. E.g., how does one specify a
RemoveCommand that removes the appropriate instance, or make sure that
the change recorder doesn't get confused, and that the cross reference
adapter knows to consider there could be more than one reference, so
removing one shouldn't necessarily forget about the reference? I'd
need to revisit much of the downstream framework to ensure that general
support for this generally works...

Of course can can specialize your list's getter so that its list allow
uniqueness and then hope for the best. It's often the, e.g., case
https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325#c4, that folks
discover later that this non-uniqueness isn't really the best semantic
representation in the first place...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Add duplicated elements to EList [message #1450200 is a reply to message #1450114]

Wed, 22 October 2014 07:40

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

The non-Unique use case is certainly uncommon, hence the longevity of
the bug. But it is not unreasonable. EMF code generation is usually
accurate and so the associated EMF malfunction comes as a big surprise
and something of a debugging nightmare.

Consider the modeling of e.g. Map<K,V> using a positionally correlated
list of TemplateParameterType. This list is correctly non-unique since
there is no reason why Map<String,String> should be prohibited.

I have successfully avoided exactly this problem by code such as:

/**
* 
* 
* @generated NOT FIXME workaround BUG 89325
*/
@SuppressWarnings("serial")
@Override
public List<CGClass> getTemplateParameters() {
if (templateParameters == null) {
templateParameters = new EObjectEList<CGClass>(CGClass.class, this,
CGModelPackage.CG_CLASS__TEMPLATE_PARAMETERS)
{
@Override
protected boolean isUnique() {
return false;
}
};
}
return templateParameters;
}

Regards

Ed Willink

On 22/10/2014 06:27, Ed Merks wrote:
> Thomas,
>
> Comments below.
>
> On 21/10/2014 8:55 PM, Thomas Zwickl wrote:
>> Hello,
>>
>> I've today encountered that although I've set the flag Unique for a
>> reference in the EMF model to false, that I still cannot add
>> duplicated objects. It's a one way reference where I want to add
>> several objects, which can also be the same objects. The only thing
>> that's interesting for me is the order the objects appear in the list.
>> Does anyone know what's the reason why I cannot add duplicated
>> objects, despite the fact that I deactivated uniqueness?
>>
>> I have already searched for the problem in the internet and
>> encountered the following very old bug report, which still seems to be
>> active:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325
> Yes, it's an old issue. (Strange that I wasn't on the CC list.)
>>
>> Any ideas if this bug has already been resolved in one of the versions
>> or if anyone is working on solving this problem?
> No, not really.
>> Any help or pointers would be appreciated.
> It's clear from the implementation that the limitation is intentional.
> As mentioned in there, the problem is that downstream assumptions in the
> rest of the framework count on this. E.g., how does one specify a
> RemoveCommand that removes the appropriate instance, or make sure that
> the change recorder doesn't get confused, and that the cross reference
> adapter knows to consider there could be more than one reference, so
> removing one shouldn't necessarily forget about the reference? I'd
> need to revisit much of the downstream framework to ensure that general
> support for this generally works...
>
> Of course can can specialize your list's getter so that its list allow
> uniqueness and then hope for the best. It's often the, e.g., case
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325#c4, that folks
> discover later that this non-uniqueness isn't really the best semantic
> representation in the first place...
>

Report message to a moderator

Re: Add duplicated elements to EList [message #1450225 is a reply to message #1450200]

Wed, 22 October 2014 08:10

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Ed,

Comments below.

On 22/10/2014 9:40 AM, Ed Willink wrote:
> Hi
>
> The non-Unique use case is certainly uncommon, hence the longevity of
> the bug. But it is not unreasonable.
That's why it's not fixed and not closed as won't fix.
> EMF code generation is usually accurate and so the associated EMF
> malfunction comes as a big surprise and something of a debugging
> nightmare.
Associated malfunction?
>
> Consider the modeling of e.g. Map<K,V> using a positionally correlated
> list of TemplateParameterType.
Such a thing is modeled by Ecore itself.
> This list is correctly non-unique since there is no reason why
> Map<String,String> should be prohibited.
It's not a good example because of course you can have Map<Map<String,
String>, Map<String, String>>, i.e., these aren't simply references but
rather "expressions" that reference things, i.e., EGenericTypes as
modeled in Ecore.
>
> I have successfully avoided exactly this problem by code such as:
>
> /**
> * 
> * 
> * @generated NOT FIXME workaround BUG 89325
> */
> @SuppressWarnings("serial")
> @Override
> public List<CGClass> getTemplateParameters() {
> if (templateParameters == null) {
> templateParameters = new
> EObjectEList<CGClass>(CGClass.class, this,
> CGModelPackage.CG_CLASS__TEMPLATE_PARAMETERS)
> {
> @Override
> protected boolean isUnique() {
> return false;
> }
> };
> }
> return templateParameters;
> }
>
> Regards
>
> Ed Willink
So in your case, template parameters can't in turn make use of types
with template arguments; generally such things are recursively permitted.

A different example that comes to mind is modeling a method's signature,
java.lang.reflect.Method.getParameterTypes(). So yes, the problem does
arise; but even here, it's more likely this is derived from something
else, i.e., java.lang.reflect.Method.getGenericParameterTypes(), but of
course that wasn't the case before Java 5.0.
>
>
>
> On 22/10/2014 06:27, Ed Merks wrote:
>> Thomas,
>>
>> Comments below.
>>
>> On 21/10/2014 8:55 PM, Thomas Zwickl wrote:
>>> Hello,
>>>
>>> I've today encountered that although I've set the flag Unique for a
>>> reference in the EMF model to false, that I still cannot add
>>> duplicated objects. It's a one way reference where I want to add
>>> several objects, which can also be the same objects. The only thing
>>> that's interesting for me is the order the objects appear in the list.
>>> Does anyone know what's the reason why I cannot add duplicated
>>> objects, despite the fact that I deactivated uniqueness?
>>>
>>> I have already searched for the problem in the internet and
>>> encountered the following very old bug report, which still seems to be
>>> active:
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325
>> Yes, it's an old issue. (Strange that I wasn't on the CC list.)
>>>
>>> Any ideas if this bug has already been resolved in one of the versions
>>> or if anyone is working on solving this problem?
>> No, not really.
>>> Any help or pointers would be appreciated.
>> It's clear from the implementation that the limitation is intentional.
>> As mentioned in there, the problem is that downstream assumptions in the
>> rest of the framework count on this. E.g., how does one specify a
>> RemoveCommand that removes the appropriate instance, or make sure that
>> the change recorder doesn't get confused, and that the cross reference
>> adapter knows to consider there could be more than one reference, so
>> removing one shouldn't necessarily forget about the reference? I'd
>> need to revisit much of the downstream framework to ensure that general
>> support for this generally works...
>>
>> Of course can can specialize your list's getter so that its list allow
>> uniqueness and then hope for the best. It's often the, e.g., case
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=89325#c4, that folks
>> discover later that this non-uniqueness isn't really the best semantic
>> representation in the first place...
>>
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Add duplicated elements to EList [message #1450272 is a reply to message #1450225]

Wed, 22 October 2014 09:06

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

On 22/10/2014 09:10, Ed Merks wrote:
> Ed,
> Associated malfunction?

In the deliberately simple example, the instantiation of Map<String,
String> is 'adjusted' to Map<String> since the duplicate String argument
object is a duplicate and so the extra copy is suppressed. With a wrong
object representation all sorts of failures such as matching list length
validation will follow.

Exactly the same could happen for Map<Map<String, String>, Map<String,
String>> if all types are globally unique; we get the unique constructed
types T1 and T2:

T1 := Map<String> rather than Map<String, String>
T2 := Map<T1> rather than Map<Map<String, String>, Map<String, String>>

Indeed Ecore has related functionality but that is nothing to do with
the deliberately simple example.

Yes, this occurs with parameter lists too. Perhaps the common theme is
that support for non-unique positional lists is currently pending.

And yes, keyed lists are fundamentally better, but I see little
likelihood of major languages such as Java requiring users to write code
such as

myString.substring(endIndex := 5, beginIndex := 0)

and so avoid the hazards of misaligned arguments. Non-unique positional
lists are appropriate.

Regards

Ed Willink

Report message to a moderator

Re: Add duplicated elements to EList [message #1450328 is a reply to message #1450272]

Wed, 22 October 2014 10:33

Thomas Zwickl

Messages: 37
Registered: May 2014

Member

Hi,

so first thanks for all comments now it is clear for me why this problem is really hard to solve, because of the downstream assumption the entire framework depends on.
We have now implemented the provided solution form Merks and for our case it is working exactly as we intended it.
I know that this can be dangerous because methods like remove or indexOf won't work any more in their appropriate way, but in our case we don't need this methods we just need to iterate over the list and check in which order the elements appear ...
So more or less this solution was exactly what we were looking for ...

Quote:

/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated NOT FIXME workaround BUG 89325
*/
@SuppressWarnings("serial")
@Override
public List<CGClass> getTemplateParameters() {
   if (templateParameters == null) {
         templateParameters = new EObjectEList<CGClass>(CGClass.class, this, 
                    CGModelPackage.CG_CLASS__TEMPLATE_PARAMETERS) {
             @Override
             protected boolean isUnique() {
                 return false;
             }
      };
  }
return templateParameters;
}

Regards,
Thomas

[Updated on: Wed, 22 October 2014 10:50]

Report message to a moderator

Previous Topic:	[CDO] is it abandoned? what is alternative?
Next Topic:	Import XML model to EMF

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 07:45:46 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter