Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » abstract with copy inheritance(best practise to deal with implicit inheritance of abstract roles?)
abstract with copy inheritance [message #555937] Mon, 30 August 2010 10:08 Go to next message
Andreas Mertgen is currently offline Andreas MertgenFriend
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 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1051
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
Re: abstract with copy inheritance [message #556007 is a reply to message #555942] Mon, 30 August 2010 14:21 Go to previous messageGo to next message
Andreas Mertgen is currently offline Andreas MertgenFriend
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.

Re: abstract with copy inheritance [message #574532 is a reply to message #555937] Mon, 30 August 2010 10:43 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1051
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
Re: abstract with copy inheritance [message #574559 is a reply to message #574532] Mon, 30 August 2010 14:21 Go to previous message
Andreas Mertgen is currently offline Andreas MertgenFriend
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.
Previous Topic:Release Time!
Next Topic:Service Release 0.7.1 to match Eclipse 3.6.1
Goto Forum:
  


Current Time: Sun Dec 21 11:36:10 GMT 2014

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

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