| [XCore] Overriding implementation of a super class feature in a subclass [message #891648] |
Mon, 25 June 2012 08:04  |
Eclipse User |
|
|
|
Hi,
I have a legacy model I want to model (I am using XCore for this) in EMF.
Basically the legacy model is a table that has tons of columns. Most of
these columns are only filled if the "type" column has a certain value.
I decided to model this table using class inheritance with one base
class for common features and a subclass for each type of the entity
with the additional features relevant to the particular type defined
inside this subclass.
I would also like to provide the abstract "type" feature in the base
class that would return the value of the "type" column of the table.
Essentially the value of the Type feature would be constant for a
particular subclass, but I can not specify an override for a feature
(xcore reports an error when I try to specify a field that is already
defined for a superclass)
What are my options in this case? Can this be done?
|
|
|
|
|
| Re: [XCore] Overriding implementation of a super class feature in a subclass [message #891885 is a reply to message #891883] |
Tue, 26 June 2012 08:33  |
| Eclipse User |
|
|
|
Roland,
Yes, that's the idea.
On 26/06/2012 2:28 PM, Roland Tepp wrote:
> Thanks Ed for quick reply,
>
> My comments below as well:
>
> 25.06.2012 18:38, Ed Merks kirjutas:
>>> I would also like to provide the abstract "type" feature in the base
>>> class that would return the value of the "type" column of the table.
>> And it must be a feature, i.e., an operation won't suffice?
>
> I suppose, an operation would do just as well... Feature would simply
> "look better" in this context.
>
>>> Essentially the value of the Type feature would be constant for a
>>> particular subclass, but I can not specify an override for a feature
>>> (xcore reports an error when I try to specify a field that is already
>>> defined for a superclass)
>> You should be able to define an operation that has the same name as the
>> accessor method for the feature.
>
> Okay, so let me confirm that I understand it correctly:
>
> I can define:
>
> enum Type {
> ONE
> TWO
> THREE
> ...
> }
>
> abstract class Base {
> ...
> derived transient readonly Type ^type
> ...
> }
>
> class One extends Base {
> ...
> op Type getType(){
> return Type::ONE
> }
> ...
> }
> etc.
>
> It looks like a hackish solution, but it seems to work well enough.
> Thanks :)
>
>
> Roland
|
|
|
Powered by
FUDForum. Page generated in 0.04561 seconds
Home