> 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