Home » Modeling » EMF » XCore: overriding getters or operations with fields
| XCore: overriding getters or operations with fields [message #1183152] |
Tue, 12 November 2013 17:22  |
|
Hi,
I'm using a kind of pattern for adding convenience methods in order to
avoid instanceof calls in client code: Some base classes provide getters
for fields, returning default values (usually emptyELists or null). The
following snippet demonstrates this pattern:
------------------------------
class A {
op A[] getMore() { return emptyEList }
}
class B extends A {
contains A[] more
}
------------------------------
Even though A does not really contain "more", it is possible to call
A.getMore() in client code. This simplifies the client code dramatically.
Now, sometimes there are more complicated models, such as the following:
------------------------------
class A {
op A[] getMore() { return emptyEList }
}
class B extends A {
contains A[] more
}
class C extends B {
}
------------------------------
This works still fine. However, the following snippet produces "wrong" code:
------------------------------
package XCoreDemo
class A {
op A[] getMore() { return emptyEList }
}
class B extends A {
contains A[] more
}
class X {}
class C extends X,B {
}
------------------------------
In C, the operation "getMore" defined in A is repeated, overriding the
"correct" getter for the field. If "C extends B,X", the code works.
Apparently, Xcore or the code generation does not recognize generated
field getters to override an operation defined in a super type.
The correct way of defining the convenience method would probably be to
declare a derived feature:
------------------------------
class A {
derived A[] more get { return emptyEList }
}
------------------------------
Unfortunately, it seems as if this only works for primitive types, is
this correct? Besides, in that case, the field cannot be "overridden" in B.
Is the first problem, XCore not recognizing the generated getter to
implement the operation, a bug or a feature? In the first case, I could
write a bug report. In the second case, I also could write a bug report:
In that case, XCore should create an error when indirectly overriding an
operation with a field getter.
Regards,
Jens
|
|
|
| Re: XCore: overriding getters or operations with fields [message #1183197 is a reply to message #1183152] |
Tue, 12 November 2013 18:01  |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Jens,
Comments below.
On 12/11/2013 6:22 PM, Jens v.P. wrote:
> Hi,
>
> I'm using a kind of pattern for adding convenience methods in order to
> avoid instanceof calls in client code: Some base classes provide
> getters for fields, returning default values (usually emptyELists or
> null). The following snippet demonstrates this pattern:
>
> ------------------------------
> class A {
> op A[] getMore() { return emptyEList }
> }
> class B extends A {
> contains A[] more
> }
> ------------------------------
>
> Even though A does not really contain "more", it is possible to call
> A.getMore() in client code. This simplifies the client code dramatically.
>
> Now, sometimes there are more complicated models, such as the following:
>
> ------------------------------
> class A {
> op A[] getMore() { return emptyEList }
> }
> class B extends A {
> contains A[] more
> }
> class C extends B {
> }
> ------------------------------
>
> This works still fine. However, the following snippet produces "wrong"
> code:
>
> ------------------------------
> package XCoreDemo
>
> class A {
> op A[] getMore() { return emptyEList }
> }
> class B extends A {
> contains A[] more
> }
>
> class X {}
> class C extends X,B {
> }
> ------------------------------
>
> In C, the operation "getMore" defined in A is repeated, overriding the
> "correct" getter for the field. If "C extends B,X", the code works.
I see. That sounds like a bug in the logic for the "mixin" case. Please
open a bugzilla.
> Apparently, Xcore or the code generation does not recognize generated
> field getters to override an operation defined in a super type.
>
> The correct way of defining the convenience method would probably be
> to declare a derived feature:
>
> ------------------------------
> class A {
> derived A[] more get { return emptyEList }
> }
> ------------------------------
>
> Unfortunately, it seems as if this only works for primitive types, is
> this correct?
You can't override a feature with another feature though, so I'm not
sure what cases it ever works for. Keep in mind that the list returned
by a derived multi-valued feature still must implement InternalEList and
EStructuralFeature.Setting...
> Besides, in that case, the field cannot be "overridden" in B.
>
> Is the first problem, XCore not recognizing the generated getter to
> implement the operation, a bug or a feature?
Sounds like a bug (and one that would be reproducible even without Xcore)...
> In the first case, I could
> write a bug report.
Yes please.
> In the second case, I also could write a bug report: In that case,
> XCore should create an error when indirectly overriding an operation
> with a field getter.
I'm not sure which the second case is. The class C extends X,B { }
sounds wrong, but I'm not clear on what other case is not handled properly.
>
> Regards,
> Jens
>
>
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Tue Apr 16 13:28:41 GMT 2024
Powered by FUDForum. Page generated in 0.66108 seconds |
] 
Search
Help
Register
Login
Home
