Nathan Torkington wrote:
Damian Conway writes:
sub foo :lvalue { $foo }
post foo { die if $foo == 5 }
eval {
foo() = 5;
};
Postconditions on lvalue subs are not tested until the end of the complete
expression in which the sub is called.
"DC" == Damian Conway [EMAIL PROTECTED] writes:
DC However, I have given thought to allowing conditions to be grouped,
DC and de-activated by group. This would probably meet your need.
DC pre mymethod : group("safe-coding practice") { @_ 0 }
DC pre mymethod : group("debugging") { print @_,
What you want is a pre-condition on the overridden assignment operator.
What you want to do may involve having the suggested transactional
variables.
chaim
"NT" == Nathan Torkington [EMAIL PROTECTED] writes:
NT Damian Conway writes:
pre mymethod : group("safe-coding practice") { @_ 0 }
Hildo Biersma writes:
Hold on - post conditions are not intended to veto a change, they're
intended to terminate the program if an assertion is invalid. Hence it
should not matter if they run before or after assignment.
Given that the assertion should be "now this and that should be true",
"DC" == Damian Conway [EMAIL PROTECTED] writes:
How would you handle differentiating between safe-coding practices and
debugging type (internal) pre/post conditions?
DC Why would one bother?
There are two types, as I imagine them. Gatekeeper code. (Did the user
send me frobnitz?) and
DC However, I have given thought to allowing conditions to be grouped,
DC and de-activated by group. This would probably meet your need.
DCpre mymethod : group("safe-coding practice") { @_ 0 }
DCpre mymethod : group("debugging") { print @_, "\n"; }
Damian Conway writes:
pre mymethod : group("safe-coding practice") { @_ 0 }
pre mymethod : group("debugging") { print @_, "\n"; }
Using these for lvalue subs doesn't give you the behaviour you want:
sub foo :lvalue { $foo }
post foo { die if $foo == 5 }
eval {
foo() =
How would you handle differentiating between safe-coding practices and
debugging type (internal) pre/post conditions?
chaim
"DC" == Damian Conway [EMAIL PROTECTED] writes:
I would have assumed that a pre/post/invariant would not be used regularly,
but rather under optional control. So this
On Sun, 20 Aug 2000 16:32:16 +1000 (EST), Damian Conway said:
I think we agree.
$foo is a tied variable
$bar is a normal variable
sub zap : lvalue { return $_[0] ? $foo : $bar }
zap(1) = 5; # Goes to tied variable
So if all I want to do is make sure that certain attributes are positive
integers, I have to do this:
[ admittedly ungainly solutions snipped ]
I'd much prefer a solution where the positive-only logic was in a method
belonging to the class, rather than being
I would have assumed that a pre/post/invariant would not be used regularly,
but rather under optional control. So this would lose that feature.
chaim
"DC" == Damian Conway [EMAIL PROTECTED] writes:
So if all I want to do is make sure that certain attributes are positive
integers, I have to
Damian Conway wrote:
The lvalue accessor *shouldn't* be doing the assignment (what if an assignment
isn't what I want?).
The (overloaded) operator = should do the assignment. To whatever lvalue
the lvalue subroutine returns.
Or the "assignment" should be done by operator += or
12 matches
Mail list logo
