Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!rutgers!ucsd!ucbvax!husc6!bunny!dcr0 From: dcr0@GTE.COM (David Robbins) Newsgroups: comp.object Subject: Re: testing object oriented programs Message-ID: <9189@bunny.GTE.COM> Date: 1 Jun 90 13:15:54 GMT References: <1990May31.224646.15066@ux1.cso.uiuc.edu> Organization: GTE Laboratories, Inc., Waltham, MA Lines: 76 From article <1990May31.224646.15066@ux1.cso.uiuc.edu>, by render@m.cs.uiuc.edu (Hal Render): > In article <3754@trantor.harris-atd.com> wdavis@x102c.ess.harris.com writes: >>In article <1990May30.204110.22011@ux1.cso.uiuc.edu> render@m.cs.uiuc.edu writes: >>>Although class invariants are A Good Thing, I think that a more direct >>>mechanism that prevents a method from being redefined in a subclass >>>would be better in this case. >> >>Why do you think it is better? > > I think it is generally better to provide a direct solution to a problem > rather than a round-about one. This last statement is really a *key* point. At least part of the problem under discussion here is that a subclass may redefine methods in a way that breaks non-redefined methods. In other words, the redefined method violates some assumption the broken method makes. While it is true that one way to avoid such problems is to prevent redefinition, that is not really a direct solution to the problem. The most direct solution to the problem is to provide a means by which *every* method could *completely* specify the assumptions it makes about other methods (and variables), such that the compiler (or some other tool) could verify that no assumption was violated. This solution (were it feasible) would permit the maximum possible flexibility in redefinition, without leaving the prevention of such errors entirely up to "coding discipline" (which, as we all know, is not quite infallible :-)). But of course we recognize that the current state of the art falls a wee bit short of being able to completely and formally specify all the assumptions a method makes about the world around it. So we must look around for a more practical solution that at least partially gives us what we need. Eiffel's assertions are a definite step in the right direction. The nature of these assertions (pre- and post-conditions, class invariants) is precisely that they say something about the assumptions a method (or a class) makes. Assertions, as provided by Eiffel, have some definite shortcomings. There are many significant assumptions that are difficult or impossible to code in the form of assertions, and others that can be coded, but are non-trivial to do and/or expensive to actually check. On the other hand, the very practice of thinking about assertions helps to provide and focus some "coding discipline" in a way that can significantly mitigate the problem under discussion. In my own (somewhat limited) experience with object-oriented programming, mostly in Smalltalk and Eiffel, I have encountered the problem of redefinition breaking things that work, and have experienced the benefits of using assertions. It is certainly true that Smalltalk gives you no help in this; your only recourse is to understand the parent class(es) well enough to know what you can and cannot do when redefining a method. If you spend enough time in Smalltalk, you may actually get fairly good at this. But I have also found that the use of assertions in Eiffel is a big win, in more ways than one. Relative to the problem at hand, the use of assertions makes it much easier for me to understand what I can and cannot do when redefining a method. Even an assertion that can only be stated in the form of a comment helps. I am always in favor of a language providing, somehow, a "direct solution" to programming problems. But what is a "direct solution"? If the problem is that a given method should absolutely never be redefined, then the language should make it possible to say so. If the problem is that a given method should only be redefined in a manner that is consistent with certain assumptions, then the language should make it possible to say so. I suspect that the problem is much more often the latter than the former; but I won't claim that there is *never* a good reason to absolutely forbid redefinition. The thing is, the former problem is easy to solve with today's language technology, while the latter is hard to solve. So, naturally, we may tend to perceive the problem as one we have an easy solution for. Someone once said that if the only tool you have is a hammer, every problem tends to look like a nail. We need to continue to search for the right tool for the right job. For the moment, we don't have all the right tools for prevention of the problems that can be introduced by redefining methods; but we do have some tools (e.g., assertions) that can help. -- Dave Robbins GTE Laboratories Incorporated drobbins@bunny.gte.com 40 Sylvan Rd. ...!harvard!bunny!drobbins Waltham, MA 02254 CYA: I speak only for myself; GTE may disagree with what I say.