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.
