Trey Harris wrote:
In a message dated Fri, 29 Sep 2006, Aaron Sherman writes:
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.
So why would it generate an error? Why wouldn't it merely result in B
being abstract too, assuming that contra my prior mail, classes can be
abstract?
What use is an interface if it doesn't give you a guarantee? If I say,
"all dogs can bark," and you define a dog that can't bark, that's not
"abstract", that's a failure to meet the interface requirements of a dog.
Now, I *could* see a class being explicitly abstract. That is, defining
its own incomplete method. At that point, I have met the interface
requirement, but explicitly stated that my interface is incomplete. I'm
not sure that that has an particular standing in the language though.
That is, you could instantiate such a class and invoke the method in
question. Only at runtime would the invocation result in an error, and
perhaps you did all of this because, at runtime, you will mix in a class
or role that delivers the promised functionality:
role ripens { method ripen() {...} }
role vine_ripened { method ripen($self:) { $self.organic //= 1 } }
role fruit { does ripens; method ripen() {...} }
my fruit $orange .= new();
$orange.ripen; # error
$orange does vine_ripened;
$orange.ripen; # Now we can, though "organic" needs defining
The idea of abstract objects is certainly compelling, but I don't think
it's something we'll want to do without substantial explicitness.
role A { method x() { ... } }
class B { does A; method x() { ... } }
And here you do just that.
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.
Did you mean to have "class B" and "does A" there
You seem to be parsing multiple examples statefully. I recommend against
that.
On your last point, I think you are confusing an incomplete PRE (one
which invokes yadda) and an undefined PRE slot in a method. The latter
must be detectable as distinct for exactly the reasons you state.
