Mike Meyer <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
