Eclipse Community Forums: Objectteams » abstract with copy inheritance

Home » Language IDEs » Objectteams » abstract with copy inheritance(best practise to deal with implicit inheritance of abstract roles?)

Show: Today's Messages :: Show Polls :: Message Navigator

abstract with copy inheritance [message #555937]

Mon, 30 August 2010 10:08

Andreas Mertgen

Messages: 4
Registered: August 2010

Junior Member

Suppose we have a simple base class B with a method bar.

Let us look at the following team T0:

public abstract team class T0 {
	
	protected abstract class R {
		protected abstract void foo();
	}
	
	protected abstract class NR extends R playedBy B {
		foo <- before bar;
	}

}

Due to the abstract method foo, both roles and therefore the team have to be abstract.

Now let us have a look at a subclassing team T1:

public team class T1 extends T0 {
	
	protected class R {
		protected void foo(){...};
	}
	
	protected class NR {};

}

Here of course, we have to add the missing implementation of foo to make the role R non-abstract. However, role NR must be "overridden" as well to get rid of the abstract property.

I understand, that the mechanism has to handle the "abstract"-issue explicitly. But the resulting implementation with an empty role class seems to be a little odd. Is there a better way to deal with implicit inheritance like in this situation?

[Updated on: Mon, 30 August 2010 13:44]

Report message to a moderator

Re: abstract with copy inheritance [message #555942 is a reply to message #555937]

Mon, 30 August 2010 10:43

Stephan Herrmann

Messages: 1830
Registered: July 2009

Senior Member

Andreas Mertgen wrote on Mon, 30 August 2010 12:08

...
However, role NR must be "overriden" as well to get rid of the abstract property.

I understand, that the mechanism has to handle the "abstract"-issue explicitly. But the resulting implementation with an empty role class seems to be a little odd. Is there a better way to deal with implicit inheritance like in this situation?

In my view this is not just a matter of mechanism, but about a design choice to be made:
(1) Should T1.NR keep the abstract property from its tsuper role, meaning that it is not intended for instantion (despite having no abstract methods).
(2) Should T1.NR cancel the abstract property from its tsuper role in order to allow instantiation?

Do you think the compiler should automatically infer (2), in all cases? (So if I want T1.NR to be abstract indeed, I'd have to override it and repeat "abstract").
Do you see a (even) simpler way of expressing the property change from abstract to non-abstract?

(I wrote a slightly longer version with a contrived analogy to transitive analysis of declared exceptions, but the forum software ate that post Sad

)

what do you think?
Stephan

Report message to a moderator

Re: abstract with copy inheritance [message #556007 is a reply to message #555942]

Mon, 30 August 2010 14:21

Andreas Mertgen

Messages: 4
Registered: August 2010

Junior Member

Version 1 (as it is) is definitely what you would expect and I admit I don't have any better ideas Sad

The point is, that a property like abstract (the same with final) is set for both dimension of inheritance (explicit and implict) equally without chance of differentiation.

There are some minor restrictions, e.g. I could not make T0.NR (non-abstract) final, if I would like to force overriding of R and prohibit overriding of NR. But that is a reasonable trade-off when combining "abstract" with virtual classes and keeping it simple.

Report message to a moderator

Re: abstract with copy inheritance [message #574532 is a reply to message #555937]

Mon, 30 August 2010 10:43

Stephan Herrmann

Messages: 1830
Registered: July 2009

Senior Member

Andreas Mertgen wrote on Mon, 30 August 2010 12:08
> ...
> However, role NR must be "overriden" as well to get rid of the abstract property.
>
> I understand, that the mechanism has to handle the "abstract"-issue explicitly. But the resulting implementation with an empty role class seems to be a little odd. Is there a better way to deal with implicit inheritance like in this situation?

In my view this is not just a matter of mechanism, but about a design choice to be made:
(1) Should T1.NR keep the abstract property from its tsuper role, meaning that it is not intended for instantion (despite having no abstract methods).
(2) Should T1.NR cancel the abstract property from its tsuper role in order to allow instantiation?

Do you think the compiler should automatically infer (2), in all cases? (So if I want T1.NR to be abstract indeed, I'd have to override it and repeat "abstract").
Do you see a (even) simpler way of expressing the property change from abstract to non-abstract?

(I wrote a slightly longer version with a contrived analogy to transitive analysis of declared exceptions, but the forum software ate that post :( )

what do you think?
Stephan

Report message to a moderator

Re: abstract with copy inheritance [message #574559 is a reply to message #574532]

Mon, 30 August 2010 14:21

Andreas Mertgen

Messages: 4
Registered: August 2010

Junior Member

Version 1 (as it is) is definitely what you would expect and I admit I don't have any better ideas :(

The point is, that a property like abstract (the same with final) is set for both dimension of inheritance (explicit and implict) equally without chance of differentiation.

There are some minor restrictions, e.g. I could not make T0.NR (non-abstract) final, if I would like to force overriding of R and prohibit overriding of NR. But that is a reasonable trade-off when combining "abstract" with virtual classes and keeping it simple.

Report message to a moderator

Previous Topic:	Release Time!
Next Topic:	Service Release 0.7.1 to match Eclipse 3.6.1

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun Feb 28 06:34:49 GMT 2021

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter