We're having a blizzard in Kansas City. After breakfasting, changing
the litter box, and hiking to work through the snow, I am finally
looking at Conway's RFC 271. Guess which one of the earlier
activites it reminds me of.
I agree with Branden that the inheritance semantics is screwy.
I think DesignByContract contract enforcement is best done with
a parameter typing system of some kind (as in C++). Proper
objects don't get into invalid states (unless you smash them with
hammers, of course), so with polymorphic subs, where the
types of the arguments are part of the name of the function, and
some restrictions on C<bless>
(Did anyone RFC an extension to C<bless> that allows a type to
define a sanity checking function?)
you can't call a subroutine with an invalid argument.
The C<POST> method of defining a thing that is to be done on exiting
the current scope would make things easier rather than more complex
in my opinion, as discusses previously.
If object validity checking were incorporated int C<bless> the customary
return of an object
bless $retobj
}
would do an automatic sanity check against the requirements of the current
package. How about calling the standard function that bless refers to,
if it exists, before conferring its blessing, package::TEST ?
package compliant;
sub TEST{
# will be called at every blessing.
# compliant objects must have true cheese.
$_[0]->cheese() or die "FALSE CHEESE"
}
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"I don't care how they do it in New York"
