> Makes sense, no?
I like that quite a lot.
One question I still have is the syntax of pre/post conditions, e.g:
> method turn($direction, $how_sharp) {
> pre { $how_sharp <= 20 } is private;
> ...implementation...
> }
This is obviously how it would fall out from Apocalypse 4, "pre/post"
being basically types of exception, but I keep having nagging concerns
about it. To me, this keeps looking like "pre { ... }" is a
precondition attached to the _implementation_ of the given method, not
the _signature_ of a given method... For the "is private" case above,
it doesn't make much difference, but I keep thinking something like the
below just feels wonky (?)...
class Vehicle is interface {
attr $tilt;
attr $min_sharpness;
method turn($direction, $how_sharp) {
pre { $how_sharp <= $self.min_sharpness }
... a default implementation, if desired ...
}
}
class Car is Vehicle {
method turn { # this calls the precondition
...
$self.SUPER.turn( ... ); # ... hopefully not
twice? ...
... a derived implementation ...
}
}
class Cycle is Vehicle {
method turn { # does this call the
precondition? YES?
... a completely alternative implementation that doesn't call
super
....
}
}
Do you think it's sufficiently clear to newbies that the pre { } is
associated with the "signature" of the turn() interface method, and not
just the _implementation_ of turn() in Vehicle? e.g. I want a
precondition associated with turn() that is called for _all_
subclasses, whether they call the superclass implementation of turn()
or not, is it clear that that's going on? _IS_ it going on, in the
above?
On Thursday, October 3, 2002, at 01:11 PM, Allison Randal wrote:
> BTW, that's:
> attr $.tilt;
> Attributes are private by default.
(As a lame aside, are we going to have a concept of "private" vs.
"protected" vs. "public", or just private/public? (In other words,
does "private" permit access by subclasses?) Not recommending it, just
wondering if anyone thinks we need it.)
MikeL
