Another newbie question

[Alex Martelli]

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?  Wow!  How does Eiffel enforce this prohibition?  Forbidding
access to any attribute's attribute in an invariant?  I sure don't
remember that from my study of Eiffel, but admittedly that was in the
past.  I'm also quite dubious as to how you can then express some
invariants that can be very important, but before I delve into that I
would ask you to confirm that there's a prohibition of access to
attributes' attributes in an invariant (ideally with some URLs,
thanks!).

> You may not agree with what Meyer believes - in which case you would
> be right to reject any language he designed.

Of course I don't agree with such absurd statements of his as the fact
that you can have OO only with static typing, which would rule out
Smalltalk (for example!) from the set of OO languages; I'm hard put to
see how anybody could _agree_ with them, in fact.  Further, I believe
static typing is appropriate only in a functional language (unmodifiable
data), and untenable, as a matter of principle, in languages which let
you alter data on the fly; the IS-A relationship conjoined with
modifiable data is just too strict (e.g., you cannot state "a Circle
IS-A Ellipse" if modification exists and Ellipse has been reasonably
designed with methods set_x and set_y whose postconditions include the
fact that they modify ONLY the named axis; you typically want
covariance, but that's mathematically unsound, as it would violate
Liskov's substition principle; etc, etc) so you inevitably end up with
runtime checks instead (so that the stance of "things must be checked at
compile time" gets broken -- but then, the whole concept of contract
programming implies lots of *runtime* checks, anyway).  Still, if I
_had_ to use a statically typed OO language without being allowed to
pick a functional one, I guess I would not consider Eiffel (as a
language, net of any practical issues of implementation) necessarily
worse than, say, C++ or Java, which have their own problems.

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)...


Alex