Another newbie question

[Mike Meyer]

aleax at mail.comcast.net (Alex Martelli) writes:
> Mike Meyer <mwm at mired.org> wrote:
>> > What classes' invariants do you have to check in those cases?  E.g.,
>> > consider zim.foo.bar.baz() -- you do have to check the invariants of
>> > bar, foo AND zim, right?
>> Nope, just bar. Attributes display state, they don't let you change
>> it. Nothing you do with zim.foo or zim.foo.bar can change the state of
>> zim. The only invariants you need to check are bar's, which you do at
>> the exit to it's baz method.
> So foo's class is not allowed to have as its invariant any formula
> depending on the attributes of its attribute bar, such as "bar.x>23" or
> the like?

Of course you can do such things. But it's a silly thing to do. That
invariant should be written as x > 23 for the class bar is an instance
of. Invariants are intended to be used to check the state of the
class, not the state of arbitary other objects. Doing the latter
requires that you have to check the invariants of every object pretty
much every time anything changes.

Invariants are a tool. Used wisely, they make finding and fixing some
logic bugs much easier than it would be otherwise. Used unwisely, they
don't do anything but make the code bigger.

> I'm also quite dubious as to how you can then express some
> invariants that can be very important

Not all invariants, pre-conditions or post-conditions can be
expressed.

> Fortunately, for most of my work, I do get to use Python, Objective-C,
> or Haskell, which, albeit in very different ways, are all "purer" (able
> to stick to their principles)...

I think Eiffel is fairly pure. But practicality beats purity, so there
are places where it has to give in and deviate from it's
principles. Clearly, you don't agree with the underlying
philosoiphy. So don't use it.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.