Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » converting EXPRESS to ECORE: derived attribute
converting EXPRESS to ECORE: derived attribute [message #687123] Thu, 02 June 2011 07:49 Go to next message
John Smith is currently offline John SmithFriend
Messages: 137
Registered: July 2009
Senior Member
Hi,

in EXPRESS (some old metametamodell used in architecture) it is possible
to define an attribute A in class X, and set it as derived in class Y
which derives from class X. Ecore cannot redefine modifiers in derived
classes, any idea to model this with Ecore nevertheless?
Re: converting EXPRESS to ECORE: derived attribute [message #687132 is a reply to message #687123] Thu, 02 June 2011 14:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30442
Registered: July 2009
Senior Member
Likely Ed Willink will suggest using UML which supports a kind of
redefinition and maps it to Ecore via EAnnotation. What are you hoping
to accomplish by marking it as derived? There's not so much impact of
doing that; EcoreUtil.copy won't copy it (though it knows nothing about
UML's EAnnotations, so that won't help).


exquisitus wrote:
> Hi,
>
> in EXPRESS (some old metametamodell used in architecture) it is
> possible to define an attribute A in class X, and set it as derived in
> class Y which derives from class X. Ecore cannot redefine modifiers in
> derived classes, any idea to model this with Ecore nevertheless?
Re: converting EXPRESS to ECORE: derived attribute [message #687135 is a reply to message #687132] Fri, 03 June 2011 02:10 Go to previous messageGo to next message
John Smith is currently offline John SmithFriend
Messages: 137
Registered: July 2009
Senior Member
>>
>> in EXPRESS (some old metametamodell used in architecture) it is
>> possible to define an attribute A in class X, and set it as derived in
>> class Y which derives from class X. Ecore cannot redefine modifiers in
>> derived classes, any idea to model this with Ecore nevertheless?


> What are you hoping
> to accomplish by marking it as derived?

As I currently know WHAT the derived values are, I explicitely assign
the derive values when an instance of the subtype is created. The
disadvantage of this approach is that the assigned values get stored in
a database for example. So e.g. I thought about overwriting getA() in
AImpl and return the derived values there. I dont know if this is
compatible with CDO if I just add a getA() method in an Impl class,
since CDO retrieves the values for features reflectively, not calling
the getters I think.
Re: converting EXPRESS to ECORE: derived attribute [message #687136 is a reply to message #687135] Fri, 03 June 2011 04:38 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30442
Registered: July 2009
Senior Member
Comments below.

exquisitus wrote:
>
> >>
> >> in EXPRESS (some old metametamodell used in architecture) it is
> >> possible to define an attribute A in class X, and set it as derived in
> >> class Y which derives from class X. Ecore cannot redefine modifiers in
> >> derived classes, any idea to model this with Ecore nevertheless?
>
>
> > What are you hoping
> > to accomplish by marking it as derived?
>
> As I currently know WHAT the derived values are, I explicitely assign
> the derive values when an instance of the subtype is created.
So we're just talking about different defaults. That has nothing to do
with derived in these sense that Ecore uses; i.e., it's not a value
that's computed from other values and therefore would never need to be
copied.
> The disadvantage of this approach is that the assigned values get
> stored in a database for example.
Because eIsSet is considered true.
> So e.g. I thought about overwriting getA() in AImpl and return the
> derived values there.
Yes, probably better.
> I dont know if this is compatible with CDO if I just add a getA()
> method in an Impl class, since CDO retrieves the values for features
> reflectively, not calling the getters I think.
It depends on whether you use reflective delegation (getA would get
called) or dynamic delegation (it's more efficient and doesn't call getA).
Re: converting EXPRESS to ECORE: derived attribute [message #687369 is a reply to message #687123] Thu, 02 June 2011 14:17 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30442
Registered: July 2009
Senior Member
Likely Ed Willink will suggest using UML which supports a kind of
redefinition and maps it to Ecore via EAnnotation. What are you hoping
to accomplish by marking it as derived? There's not so much impact of
doing that; EcoreUtil.copy won't copy it (though it knows nothing about
UML's EAnnotations, so that won't help).


exquisitus wrote:
> Hi,
>
> in EXPRESS (some old metametamodell used in architecture) it is
> possible to define an attribute A in class X, and set it as derived in
> class Y which derives from class X. Ecore cannot redefine modifiers in
> derived classes, any idea to model this with Ecore nevertheless?
Re: converting EXPRESS to ECORE: derived attribute [message #687372 is a reply to message #687132] Fri, 03 June 2011 02:10 Go to previous message
John Smith is currently offline John SmithFriend
Messages: 137
Registered: July 2009
Senior Member
>>
>> in EXPRESS (some old metametamodell used in architecture) it is
>> possible to define an attribute A in class X, and set it as derived in
>> class Y which derives from class X. Ecore cannot redefine modifiers in
>> derived classes, any idea to model this with Ecore nevertheless?


> What are you hoping
> to accomplish by marking it as derived?

As I currently know WHAT the derived values are, I explicitely assign
the derive values when an instance of the subtype is created. The
disadvantage of this approach is that the assigned values get stored in
a database for example. So e.g. I thought about overwriting getA() in
AImpl and return the derived values there. I dont know if this is
compatible with CDO if I just add a getA() method in an Impl class,
since CDO retrieves the values for features reflectively, not calling
the getters I think.
Re: converting EXPRESS to ECORE: derived attribute [message #687373 is a reply to message #687135] Fri, 03 June 2011 04:38 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30442
Registered: July 2009
Senior Member
Comments below.

exquisitus wrote:
>
> >>
> >> in EXPRESS (some old metametamodell used in architecture) it is
> >> possible to define an attribute A in class X, and set it as derived in
> >> class Y which derives from class X. Ecore cannot redefine modifiers in
> >> derived classes, any idea to model this with Ecore nevertheless?
>
>
> > What are you hoping
> > to accomplish by marking it as derived?
>
> As I currently know WHAT the derived values are, I explicitely assign
> the derive values when an instance of the subtype is created.
So we're just talking about different defaults. That has nothing to do
with derived in these sense that Ecore uses; i.e., it's not a value
that's computed from other values and therefore would never need to be
copied.
> The disadvantage of this approach is that the assigned values get
> stored in a database for example.
Because eIsSet is considered true.
> So e.g. I thought about overwriting getA() in AImpl and return the
> derived values there.
Yes, probably better.
> I dont know if this is compatible with CDO if I just add a getA()
> method in an Impl class, since CDO retrieves the values for features
> reflectively, not calling the getters I think.
It depends on whether you use reflective delegation (getA would get
called) or dynamic delegation (it's more efficient and doesn't call getA).
Previous Topic:[CDO] License acceptance is preventing install
Next Topic:Re: [Teneo] MySQL does not create new tables on init
Goto Forum:
  


Current Time: Mon Sep 16 12:33:56 GMT 2019

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

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

Back to the top