From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-30 13:23:49
--- Brian McNamara <lorgon_at_[hidden]> wrote:
> I think yes, but only to the minor extent suggested above.
> Looking at the bigger picture, I think the point is that, while theory
> about class invariants can be useful both to help you choose a
> representation type, and to think about pre/post-conditions on methods
> in the public interface, this theory will not help you in the middle of
> a method body. During the execution of a method, you can break
> invariants as you see fit, provided things are all patched up again by
> the time execution gets back out to client code. As a result, in the
> middle of a method, you just have to "do the correct thing"; there
> aren't necessarily any explicit invariants around to help you out.
If you can break invariants practically at will internally
and most of the time we spend implementing "internal" methods,
then what about "don't pay for what you don't use" concept.
I believe that most developers just ignore the basic guarantees
concept all together in their daily work...but they
have to take a hit for what they don't actually use.
I was wondering if anybody on this board use
basic guarantees *explicitly* in their design
and/or implementation and how?
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk