| [Xcore] What is the advantage of "derived feature" from "operation" [message #1433879] |
Mon, 29 September 2014 07:10  |
Eclipse User |
|
|
|
Hi,
I like the fact I now able to specify behaviour in more natural way using Xcore on top of ecore. i.e less hacking on generated codes.
Questions based on eclipse wiki , how does this "derived String lastName get {...}" different from say defining an operation - "op String getLastName {..}", initially I was under impression that this works as lazy initialization - but from generated code, it does not have the actual attribute lastName, the calculation is done everytime lastName feature is called.
Additionally, "derived String lastName set {..}" how does this works? how do we access the set parameters?
Thank You.
|
|
|
| Re: [Xcore] What is the advantage of "derived feature" from "operation&am [message #1434002 is a reply to message #1433879] |
Mon, 29 September 2014 10:30  |
| Eclipse User |
|
|
|
Ravi,
Comments below.
On 29/09/2014 2:49 PM, Ravi Nallappan wrote:
> Hi,
>
> I like the fact I now able to specify behaviour in more natural way
> using Xcore on top of ecore. i.e less hacking on generated codes.
>
> Questions based on
> https://wiki.eclipse.org/Xcore#Specifying_a_Derived_Feature , how does
> this "derived String lastName get {...}" different from say defining
> an operation - "op String getLastName {..}", initially I was under
> impression that this works as lazy initialization - but from generated
> code, it does not have the actual attribute lastName, the calculation
> is done everytime lastName feature is called.
It's certainly not visibly different in the Java API, but reflectively,
it's a property, so you can see it in the properties view, for example.
>
> Additionally, "derived String lastName set {..}" how does this works?
> how do we access the set parameters?
It doesn't really work. I.e., it doesn't work at all, so while it's in
the grammar, there really no proper implementation for it. At some
point I'd like to be able to declare fields for the implementation class
(distinct from features which are reflectively visible)... But that's
not trivial and won't be done anytime soon...
>
> Thank You.
|
|
|
| Re: [Xcore] What is the advantage of "derived feature" from "operation&am [message #1434494 is a reply to message #1434002] |
Tue, 30 September 2014 02:54 |
| Eclipse User |
|
|
|
On 29.09.14 07:30, Ed Merks wrote:
> Ravi,
>
> Comments below.
>
> On 29/09/2014 2:49 PM, Ravi Nallappan wrote:
>> Hi,
>>
>> I like the fact I now able to specify behaviour in more natural way
>> using Xcore on top of ecore. i.e less hacking on generated codes.
>>
>> Questions based on
>> https://wiki.eclipse.org/Xcore#Specifying_a_Derived_Feature , how does
>> this "derived String lastName get {...}" different from say defining
>> an operation - "op String getLastName {..}", initially I was under
>> impression that this works as lazy initialization - but from generated
>> code, it does not have the actual attribute lastName, the calculation
>> is done everytime lastName feature is called.
> It's certainly not visibly different in the Java API, but reflectively,
> it's a property, so you can see it in the properties view, for example.
a feature value is observable using Adapters which does not work for
operations.
Tom
|
|
|
Powered by
FUDForum. Page generated in 0.02987 seconds
Home