Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » How to implement derived and volatile getters?
How to implement derived and volatile getters? [message #421964] Tue, 19 August 2008 14:46 Go to next message
Kim Horne is currently offline Kim HorneFriend
Messages: 22
Registered: July 2009
Junior Member
I've got a 0-* reference on an EClass instance that is transient and
derived from another 0-* collection on the same EClass. The generated
implementation for this reference throws an unsupported operation
exception and contains a comment that suggest that I use a subclass of
EcoreEList in my customized implementation. Is there an example somewhere
that shows what an implementation of such a method might look like?
Re: How to implement derived and volatile getters? [message #421967 is a reply to message #421964] Tue, 19 August 2008 17:56 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Kim,

Comments below.

Kim Horne wrote:
> I've got a 0-* reference on an EClass instance that is transient and
> derived from another 0-* collection on the same EClass.
I guess it's volatile too or you'd have an implementation generated, and
that would show which class is good to use. Is this feature
unchangeable? I.e., you don't want to allow editing of it? Something
like this might do the trick:

new EcoreEList.UnmodifiableEList.FastCompare<EGenericType>
(this, XyzPackage.Literals.ABC__DEF, result.size(),
result.toArray());

Where result is some list.
> The generated implementation for this reference throws an unsupported
> operation exception and contains a comment that suggest that I use a
> subclass of EcoreEList in my customized implementation. Is there an
> example somewhere that shows what an implementation of such a method
> might look like?
If you make the feature not volatile, you could regenerate to see what
list would look like and then change it back. I'm assuming this feature
is not a containment feature...


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: How to implement derived and volatile getters? [message #421973 is a reply to message #421967] Tue, 19 August 2008 19:37 Go to previous messageGo to next message
Kim Horne is currently offline Kim HorneFriend
Messages: 22
Registered: July 2009
Junior Member
Ed Merks wrote:

> Kim,

> Comments below.

> Kim Horne wrote:
>> I've got a 0-* reference on an EClass instance that is transient and
>> derived from another 0-* collection on the same EClass.
> I guess it's volatile too or you'd have an implementation generated, and
> that would show which class is good to use. Is this feature
> unchangeable? I.e., you don't want to allow editing of it? Something
> like this might do the trick:

> new EcoreEList.UnmodifiableEList.FastCompare<EGenericType>
> (this, XyzPackage.Literals.ABC__DEF, result.size(),
> result.toArray());
> Where result is some list.

I kind of thought it should look something like that, but as a n00b, stuff
like EcoreEList.UnmodifiableEList.FastCompare scares me in much the same
way that balloons and thunderstorms scare me (ie: a lot).

>> The generated implementation for this reference throws an unsupported
>> operation exception and contains a comment that suggest that I use a
>> subclass of EcoreEList in my customized implementation. Is there an
>> example somewhere that shows what an implementation of such a method
>> might look like?
> If you make the feature not volatile, you could regenerate to see what
> list would look like and then change it back. I'm assuming this feature
> is not a containment feature...

This feature should be a non-modifiable subset of another feature. It's
basically a view onto that feature. Would it make more sense for me to
implement this as an operation instead? At times like this I ask myself:
"WWED?"
Re: How to implement derived and volatile getters? [message #421974 is a reply to message #421973] Tue, 19 August 2008 19:52 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Kim,

Comments below.


Kim Horne wrote:
> Ed Merks wrote:
>
>> Kim,
>
>> Comments below.
>
>> Kim Horne wrote:
>>> I've got a 0-* reference on an EClass instance that is transient and
>>> derived from another 0-* collection on the same EClass.
>> I guess it's volatile too or you'd have an implementation generated,
>> and that would show which class is good to use. Is this feature
>> unchangeable? I.e., you don't want to allow editing of it?
>> Something like this might do the trick:
>
>> new EcoreEList.UnmodifiableEList.FastCompare<EGenericType>
>> (this, XyzPackage.Literals.ABC__DEF, result.size(),
>> result.toArray());
>> Where result is some list.
>
> I kind of thought it should look something like that, but as a n00b,
> stuff like EcoreEList.UnmodifiableEList.FastCompare scares me in much
> the same way that balloons and thunderstorms scare me (ie: a lot).
Such a pretty name. :-P
>>> The generated implementation for this reference throws an
>>> unsupported operation exception and contains a comment that suggest
>>> that I use a subclass of EcoreEList in my customized
>>> implementation. Is there an example somewhere that shows what an
>>> implementation of such a method might look like?
>> If you make the feature not volatile, you could regenerate to see
>> what list would look like and then change it back. I'm assuming this
>> feature is not a containment feature...
>
> This feature should be a non-modifiable subset of another feature.
> It's basically a view onto that feature. Would it make more sense for
> me to implement this as an operation instead? At times like this I
> ask myself: "WWED?"
I'd be torn. Either way is fine. As a feature it would be reflectively
more visible and accessible. I.e., I could find that feature and call
eGet for it, whereas for an operation there'd be little I could do with
it...
>
>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:Fixing an Dangling Reference
Next Topic:[Teneo] Integrity constraint violation on delete
Goto Forum:
  


Current Time: Thu Mar 28 19:50:36 GMT 2024

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

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

Back to the top