[EMAIL PROTECTED] writes:
: Is it POST, LAST or LAST, POST, at runtime?
Obviously you want to put the assertion checking after the cleanup,
so LAST, POST.
: How does one enforce the no side-effects rule, and how deeply does it
: traverse?
Dunno. Could warn or fail on assignment to any non-lexical or
non-local lexical as a start. Maybe we could warn or fail on method
calls known to modify an object. But I don't know how much
technological enforcement we can achieve without an unnecessarily
fascist declaration policy. I expect the most important thing would be
to encourage people to think that way.
: Do I remember right that 'return' creates a control exception?
Yes, unless it can be optimized to a goto.
: Do KEEP and UNDO take the place of CATCH within a block? (ie, you may either
: CATCH, or you may KEEP and UNDO, but not both?) If all three are allowed,
: what is the exception handling order?
I think of KEEP and UNDO as LAST blocks, not CATCH blocks, because
there can only be one CATCH block, but there can be multiple LAST
blocks. They just happen to have secret knowledge of whether the block
was successful or not. How that interacts with a previously occurring
CATCH is still a little up in the air. I suppose it should be possible
for a CATCH to signal success even though a "fatal" exception was caught.
I wouldn't think that would be the default, though. Maybe it has to
wipe out $! manually or change $! to an innocuous exception type for
the KEEPs to run instead of the UNDOs.
: Which blocks may you have more than one of within the same block, and in
: what order will they execute?
As far as I know, only CATCH is limited to one, and the basic principle
for order is that things that run at the beginning of something run in
forward order, while things that run at the end run in reverse order.
: In one cannot (or does not) inherit a PRE, POST, or LAST block, is there a
: way to add one without recreating the entire block.
I expect PRE and POST could inherit automatically according to the
usual rules of DbC, though how you implement that is something other
people have thought about more than me. I think that LAST doesn't
inherit. If you want to share common code, there's this neat Perl 6
invention called "subroutines" you can use.
: When you say inheritence (which implies a sub), not inheriting only applies
: to the outer-most scope - the sub scope - currect? Any container blocks
: should still have their full semantics preserved, so that an embedded while
: block, for instance, would still have its corresponding LAST, I hope.
Yes.
: If that were the case, could you then get around the inheritence issue by
: enclosing the entire body of the sub inside its own block? (I'm not saying
: that that's a good idea, just asking whether it could be done.)
Yes.
: sub non_method {
: loop {
: PRE {
: print "PRE\n"; # Is printing a side-effect?
Gee, maybe warnings and failures are side effects, and should be also
prohibited. :-)
Like I said earlier, I think the important thing is to make people
think about it, not to continually frustrate them. I'd be inclined to
let people choose their own level of pain by setting DbC strictness
thresholds.
Larry
