Home » Modeling » EMF » Best way to handle unmodifiable collections
| Best way to handle unmodifiable collections [message #543201] |
Mon, 28 June 2010 12:48  |
Eclipse User |
|
|
|
Hi,
Often, I find that I would like to create a list of objects that's
modifiable from within my model package, but that is unmodifiable to the
outside world. What I usually do now is create two features, one with
suppressedGetVisibility="true" that holds the actual list, which I can
call from inside the model packages, and another one that is derived,
transient, volatile and non-changeable, which returns an unmodifiable
view of the former list.
As this seems rather complicated for a common problem, I was wondering:
is there a better way to do this?
Thanks,
J.-P.
|
|
|
| Re: Best way to handle unmodifiable collections [message #543206 is a reply to message #543201] |
Mon, 28 June 2010 12:55  |
| Eclipse User |
|
|
|
J.-P.
Comments below.
J.-P. Pellet wrote:
> Hi,
>
> Often, I find that I would like to create a list of objects that's
> modifiable from within my model package, but that is unmodifiable to
> the outside world. What I usually do now is create two features, one
> with suppressedGetVisibility="true" that holds the actual list, which
> I can call from inside the model packages,
And which is available reflectively for use by the copier and the
deserializer.
> and another one that is derived, transient, volatile and
> non-changeable, which returns an unmodifiable view of the former list.
>
> As this seems rather complicated for a common problem, I was
> wondering: is there a better way to do this?
Not really. I suppose with the support we added in 2.6 for using
annotations to support the behavior of derived features, it would be
possible to achieve this result purely with annotations and no hand
written changes.
>
> Thanks,
> J.-P.
|
|
| |
| Re: Best way to handle unmodifiable collections [message #543215 is a reply to message #543207] |
Mon, 28 June 2010 13:12 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------020002060808050305050401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
J.-P,
Comments below.
J.-P. Pellet wrote:
> Ed,
>
> Thanks for your reply.
>
>>> As this seems rather complicated for a common problem, I was
>>> wondering: is there a better way to do this?
>> Not really.
>
> OK, good to know.
>
>> I suppose with the support we added in 2.6 for using annotations to
>> support the behavior of derived features, it would be possible to
>> achieve this result purely with annotations and no hand written changes.
>
> Sounds good. Any pointers/documentation on this?
http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Suppor t_for_Feature_Setting_Delegates
> When you say "annotations", do you mean Javadoc annotations or Ecore
> annotations?
Ecore, but of course @model in the Javadoc can be used to specify those
too...
>
> Thanks a lot,
> J.-P.
--------------020002060808050305050401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
J.-P,<br>
<br>
Comments below.<br>
<br>
<br>
J.-P. Pellet wrote:
<blockquote cite="mid:i0akue$sfu$1@build.eclipse.org" type="cite">Ed,
<br>
<br>
Thanks for your reply.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">As this seems rather complicated for a
common problem, I was wondering: is there a better way to do this?
<br>
</blockquote>
Not really.
<br>
</blockquote>
<br>
OK, good to know.
<br>
<br>
<blockquote type="cite">I suppose with the support we added in 2.6
for using annotations to support the behavior of derived features, it
would be possible to achieve this result purely with annotations and no
hand written changes.
<br>
</blockquote>
<br>
Sounds good. Any pointers/documentation on this? </blockquote>
<blockquote><a
href=" http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Suppor t_for_Feature_Setting_Delegates"> http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Suppor t_for_Feature_Setting_Delegates</a><br>
</blockquote>
<blockquote cite="mid:i0akue$sfu$1@build.eclipse.org" type="cite">When
you say "annotations", do you mean Javadoc annotations or Ecore
annotations?
<br>
</blockquote>
Ecore, but of course @model in the Javadoc can be used to specify those
too...<br>
<blockquote cite="mid:i0akue$sfu$1@build.eclipse.org" type="cite"><br>
Thanks a lot,
<br>
J.-P.
<br>
</blockquote>
</body>
</html>
--------------020002060808050305050401--
|
|
|
| Re: Best way to handle unmodifiable collections [message #543266 is a reply to message #543215] |
Mon, 28 June 2010 17:20 |
| Eclipse User |
|
|
|
Hi
You may also find that http://wiki.eclipse.org/MDT/OCLinEcore is useful.
Regards
Ed Willink
On 28/06/2010 18:12, Ed Merks wrote:
> J.-P,
>
> Comments below.
>
>
> J.-P. Pellet wrote:
>> Ed,
>>
>> Thanks for your reply.
>>
>>>> As this seems rather complicated for a common problem, I was
>>>> wondering: is there a better way to do this?
>>> Not really.
>>
>> OK, good to know.
>>
>>> I suppose with the support we added in 2.6 for using annotations to
>>> support the behavior of derived features, it would be possible to
>>> achieve this result purely with annotations and no hand written changes.
>>
>> Sounds good. Any pointers/documentation on this?
>
> http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Suppor t_for_Feature_Setting_Delegates
>
>> When you say "annotations", do you mean Javadoc annotations or Ecore
>> annotations?
> Ecore, but of course @model in the Javadoc can be used to specify those
> too...
>>
>> Thanks a lot,
>> J.-P.
|
|
|
Goto Forum:
Current Time: Wed Jul 02 15:55:23 EDT 2025
Powered by FUDForum. Page generated in 0.04117 seconds |
Home