| How to implement derived and volatile getters? [message #421964] |
Tue, 19 August 2008 10:46  |
Eclipse User |
|
|
|
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 #421973 is a reply to message #421967] |
Tue, 19 August 2008 15:37  |
| Eclipse User |
|
|
|
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 15:52 |
| Eclipse User |
|
|
|
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...
>
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.20308 seconds
Home