> > [concerns over conflation of post-processing and post-assertions]
>
> Having read A4 thoroughly, twice, this was my only real concern
> (which contrasted with an overall sense of "wow, this is so cool").
Larry and I discussed it over breakfast the next day, and concluded that
there will be a
Me wrote:
> > [concerns over conflation of post-processing and post-assertions]
>
> Having read A4 thoroughly, twice, this was my only real concern
> (which contrasted with an overall sense of "wow, this is so cool").
>
> --me
Yes, very, very cool.
I especially liked how RFC 88 was "accepted wi
"Me" <[EMAIL PROTECTED]> writes:
>> [concerns over conflation of post-processing and post-assertions]
>
> Having read A4 thoroughly, twice, this was my only real concern
> (which contrasted with an overall sense of "wow, this is so cool").
I think that people have sort of got used to the fact th
> [concerns over conflation of post-processing and post-assertions]
Having read A4 thoroughly, twice, this was my only real concern
(which contrasted with an overall sense of "wow, this is so cool").
--me
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 m
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.
I can't help feeling that contract/assertion checking
should not
