|
|
| Re: [EMF] Resolving and non resolving list methods [message #782728 is a reply to message #782547] |
Tue, 24 January 2012 09:59   |
 Rimvydas
Messages: 47
Registered: July 2009 |
Member |
|
|
Hello Ed,
Thank you for the answer.
Could you confirm that the following is correct:
java.util.List
All methods should resolve.
Exception: remove(int)
org.eclipse.emf.common.util.EList
All methods should not resolve.
org.eclipse.emf.ecore.util.InternalEList
All methods that starts with "basic" should not resolve.
How about other methods (addUnique, addAllUnique, setUnique) ?
Thanks in advance for the answer.
Regards,
Rimvydas Vaidelis
On 1/24/2012 1:12 AM, Ed Merks wrote:
> Rimvydas,
>
> Comments below.
>
> On 23/01/2012 7:55 PM, Rimvydas Vaidelis wrote:
>> Hello,
>>
>> I would like to implement my own implementation of InternalEList and
>> use it in my model.
> It's generally better to reuse existing implementations. There are quite
> a few variations, (see the hierarchy of InternalEList) at least one of
> which is likely to be appropriate...
>> I want to persist the model using standard XMI resource. In
>> implementation of XMI load/save code I see that some of the list
>> methods must not resolve values (e.g remove(int)) and other methods
>> should resolve proxies.
> Yes.
>>
>> Is there any set list that specifies which list methods should be non
>> resolving and which should be resolving?
> The regular list API should generally resolve. InternalEList has "basic"
> methods that, as documented, should not resolve. That's pretty much all
> there is to know.
>>
>> Thanks in advance for an answer.
>>
>> Regards,
>>
>> Rimvydas Vaidelis
|
|
|
| Re: [EMF] Resolving and non resolving list methods [message #782738 is a reply to message #782728] |
Tue, 24 January 2012 10:32 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
Rimvydas,
Comments below.
On 24/01/2012 10:59 AM, Rimvydas Vaidelis wrote:
> Hello Ed,
>
> Thank you for the answer.
>
> Could you confirm that the following is correct:
>
> java.util.List
> All methods should resolve.
> Exception: remove(int)
The point being the user should not see a proxy come out.
>
> org.eclipse.emf.common.util.EList
> All methods should not resolve.
The move methods. The one that takes an object will need to find the
object (indexOf) and that will resolve.
> org.eclipse.emf.ecore.util.InternalEList
> All methods that starts with "basic" should not resolve.
> How about other methods (addUnique, addAllUnique, setUnique) ?
Those just skip uniqueness checking but otherwise are the same as
add/addAll/set.
>
> Thanks in advance for the answer.
>
> Regards,
>
> Rimvydas Vaidelis
>
>
> On 1/24/2012 1:12 AM, Ed Merks wrote:
>> Rimvydas,
>>
>> Comments below.
>>
>> On 23/01/2012 7:55 PM, Rimvydas Vaidelis wrote:
>>> Hello,
>>>
>>> I would like to implement my own implementation of InternalEList and
>>> use it in my model.
>> It's generally better to reuse existing implementations. There are quite
>> a few variations, (see the hierarchy of InternalEList) at least one of
>> which is likely to be appropriate...
>>> I want to persist the model using standard XMI resource. In
>>> implementation of XMI load/save code I see that some of the list
>>> methods must not resolve values (e.g remove(int)) and other methods
>>> should resolve proxies.
>> Yes.
>>>
>>> Is there any set list that specifies which list methods should be non
>>> resolving and which should be resolving?
>> The regular list API should generally resolve. InternalEList has "basic"
>> methods that, as documented, should not resolve. That's pretty much all
>> there is to know.
>>>
>>> Thanks in advance for an answer.
>>>
>>> Regards,
>>>
>>> Rimvydas Vaidelis
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03167 seconds
] 
Search
Help
Register
Login
Home
