Jonathan Lang wrote:
I hope not.  My understanding is that '{ ... }' is supposed to
represent the notion of abstract routines: if you compose a role that
has such routines into a class or package, I'd expect the package to
complain bitterly if any such routines are left with yada-yadas as
their codeblocks, on the basis that while roles can be abstract,
classes and packages should not be.


First the high-level point: I'm dropping the RFC, because, as TimToady pointed out on IRC, we're not quite far enough down the line to see the breadth or certainty of the need yet.

That said, this is a different point, above and I think it's an easy one to take on.

role A { method x() {...} }
class B { does A; }

does generate an error per "If a role merely declares methods without defining them, it degenerates to an interface:" from S12.

However, that's not to say that a class can't be abstract, just that a class that does an interface (a role with nothing but abstract methods) must implement the role's interface.

Nothing is said of what happens when you compose a role that has both defined and undefined methods, but IMHO, that's at most a warning if they remain undefined after composition, since you might want to use that class as a trait at runtime where target objects will define that method.

Certainly this:

class A { method x() {...} }

is very explicit, and should be allowed, given that it is a promise that "sometime before x is called, it will be defined." It's a runtime error if that promise is not kept.

Reply via email to