|
|
Re: How to implement derived and volatile getters? [message #421973 is a reply to message #421967] |
Tue, 19 August 2008 19:37 |
Kim Horne 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 |
Ed Merks Messages: 33142 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/
|
|
|
Powered by
FUDForum. Page generated in 0.04641 seconds