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 "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?]]>Andreas Mertgen2010-08-30T10:08:58-00:00Re: abstract with copy inheritancehttps://www.eclipse.org/forums/index.php/mv/msg/181077/984720/#msg_984720
I'm intrigued by the example, tempted to say we could simply fix the compiler.

But then I wonder: T1.NR has an implementation for foo, OK, but it could still be abstract even if it contains no abstract methods.
In Java, marking a class as abstract is more than acknowledging that it has one or more abstract methods, it could simply be a way to specify: "not intended for instantiation".

In this light the "empty" role is an relevant override (and should be marked with @Override) re-declaring the role from abstract to non-abstract.

Let's briefly try the other way around: assume that without overriding the implicit role T1.NR would be non-abstract: how would I achieve it to be abstract (to prohibit instantiation)? I would need to "override" the abstract role with an empty abstract role. This might be a contrived example but this solution certainly feels even more weird.

From this I conclude it is indeed better, to not implicitly "improve" the role from abstract to not-abstract. Even if this is likely what you want, if it ever happens that you don't want this "improvement", you'll be much bewildered by this unsolicited magic.