CODEWITHSUNDEEP
eclipsemodelingeclipse-emfemfecore
cara
cara

Reputation: 1042

Override the value of an attribute in a derived Ecore-class (EMF)

I'm aware of the fact that I cannot override or redefine attributes as a whole in an ecore-based model when it comes to inheritance. But can I somehow assign a new value to an existing, inherited attribute?

E.g. Class A defines the attribute name which is a string, the default value is set to 'defaultA'. Class B inherits from Class A and name should have the value 'defaultB'.

I tried to just reimplement the attribute with the same name and datatype in Class B, but I cannot create a genmodel from that ("There may not be two features named 'name'").

Isn't it even possible to change the value of an inherited attribute?

Upvotes: 5

Views: 2887

Answers (3)

Lii
Lii

Reputation: 12112

This rather hackish alternative is to declare an operation in the subclass with the same name as the feature getter name.

This is a light-weight variation of Viliam Simko's solution.

With this solution you will not have a proper name feature in Class B, but when then name feature in Class A is accessed your getter in Class B will be called instead.

I don't even know if this is really allowed. But it seems to be working with EMF 2.13.0, Xcore 1.5.0.

Example:

class ClassA {
    String name
}

class ClassB extends ClassA {
    op String getName() {
        return "Name B"
    }
}

Upvotes: 1

Viliam Simko
Viliam Simko

Reputation: 1841

Attributes cannot be overridden in plain EMF but there is a workaround through OCL. (Of course, you can generate Java code and implement the attributes as needed but it won't work in the Eclipse instance where you created the meta-model.)

The trick is that operations can be overridden in EMF and through OCL you can implement the operations as needed.

Below is a minimal example (written in OCLinEcore editor) that defines a meta-model consisting of classes A and B. The class A introduces an attribute label which is just redirected to the operation computeLabel(). Class 'B' provides a different implementation for the computeLabel() operation.

package workaround : workaround = 'workaround' {
    class A {
        operation computeLabel() : String {
            body: 'labelA';
        }
        attribute label : String {
            derivation: computeLabel();
        }
    }
    class B extends A {
        operation computeLabel() : String {
            body: 'labelB';
        }
    }
}

You can test it by creating a dynamic instance of class B and opening the B.xmi file in the standard Sample Reflective Ecore Model Editor. You'll then see:

enter image description here

Upvotes: 4

Ed Merks
Ed Merks

Reputation: 159

No, that's not supported. The field for the feature is declared in the base class and that assigns the default defined for the feature...

Upvotes: 4

Related Questions