From: David Whipp [mailto:[EMAIL PROTECTED]] > > Apo4, when introducing POST, mentions that there is a > corresponding "PRE" block "for design-by-contract > programmers". > > However, I see the POST block being used as a finalize; > and thus allowing (encouraging?) it to have side effects.
It may very well be the case that a procedure's POST block could have side effects. However, if Larry and Damian are on the same frequency... then a _method_'s PRE/POST blocks will not have side effects. At least that is what I perhaps incorrectly inferred from one of previous discussion which Damian participated in on the perl6-language list about subroutine wrappers, Hook::LexWrapper, or whatever the means to the ends were in that thread. > I can't help feeling that contract/assertion checking > should not have side effects. Furthermore, there should > be options to turn off PRE/POST processing for higher > performance. Perhaps we'll learn more about contracts > (inc. invariants, inheritance) in a later apo? I hope so. I am particularly interested to hear how PRE/POST blocks will work in the context of methods and inheritence. > Will we still use the Class::Contract module? Your guess is as good as mine. It looks like there will be fewer reasons for most people to use it. Especially if all you need is assertions. IMO: Its nice just to hear Larry say "design-by-contract" programmers, and know that he's still talking about Perl ;) We'll just have to see how Perl6 DBC support works out with regards to encapsulation, inheritence, and Class::Contract's other odds and ends. But I imagine support for things like a POST block checking an object against its previous state via &old, and things like shortening and flattening, etc. will still require a Class::Contract.
