On Thu, 3 Oct 2002, Michael G Schwern wrote:
: On Thu, Oct 03, 2002 at 05:23:08PM -0500, Jonathan Scott Duff wrote:
: > I don't know, but I think it's supposed to be like this:
: >
: > # part of the signature
: > method turn($dir,$ang) is pre { $ang <= 20 } {
: > ...
: > }
: >
: > # part of the implementation
: > method turn($dir,$ang) {
: > PRE { $ang <= 20 }
: > ...
: > }
: >
: > turn() methods of derived classes would inherit the precondition in the
: > first case but not the second. I don't know why you'd want to do this
: > exactly, but it seems to me that perl should allow it.
:
: I see us already smashing too many things into the method signature as it
: is. It will rapidly get messy if you have a method with a complex signature
: and a handful of attributes and preconditions.
:
: Also, where do the postconditions go? In the signature at the front? That
: doesn't make sense, it should go at the end so you can keep them in mind
: when you're writing the return code.
:
: Consider...
:
: method foo($this, $that) is memoized is something
: is pre { $this <= 42 }
: is pre { $that == $this / 2 }
: is pre { a lot of code which is hard to
: shove into a block of code
: this close to the right margin }
: is post { what is a post condition
: doing at the front? }
: {
: ...
: }
:
: They can, of course, be pulled back from the margin:
:
: method foo($this, $that) is memoized is something
: is pre { $this <= 42 }
: is pre { $that == $this / 2 }
: is pre { now we have a little bit more room to play with using
: a differnt indentation style }
: is post { but post conditions are still distanced from the
: code which return()s }
: {
: ...
: }
:
: I realize that conditions are technically part of the signature, but putting
: them in there paints us into a stylistic corner.
Hmm. It sounds like a cry for help. :-)
method foo($this, $that) is memoized is something
{
...
}
# Additionaly...
also &foo
is pre { $this <= 42 }
is pre { $that == $this / 2 }
is pre { now we have a little bit more room to play with using
a differnt indentation style }
is post { but post conditions are still distanced from the
code which return()s };
One is tempted to make it:
also note that &foo is pre { ... }
It might be possible to allow "is" after the {...} block, much like an C<else> block.
But an "also" would let us defer all the extras to the end of the class definition.
: I'm also not fond of the pre/PRE distinction. Few of the other special
: blocks (given, eval, try, invar, etc...) use all cap names. At least I hope
: not.
All caps indicates a BEGIN-like block that is not evaluated inline, but
sets a property in the surrounding scope. It's a useful distinction.
: Simply attaching an "is private" attribute to a pre condition block
: seems the simplest way to go about it.
Except that you'd have to parenthesize it:
is pre ({...} is private)
Otherwise it'd merely privatize whatever the first "is" is "issing".
: Just like any other private thing,
: it's not inherited and not visible outside the current class. "pre" vs
: "PRE" doesn't convey that meaning.
Well, yes it does, because the pre is in the declaration, and the
PRE is embedded in the implementation, albeit known at compile time.
Not that we're necessarily going to have PRE/POST blocks anyway,
but that's how they'd parse.
I think it'd be kinda strange (but possible (but possibly useless))
to have a declaration like:
sub foo {
...
PRE { @_ > 0 }
}
That is, the precondition would go away as soon as you redefined the {...}.
Larry
