Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.eiffel Subject: Re: Inheritance and Information Hiding Message-ID: <1991Jan31.213146.4306@Think.COM> Date: 31 Jan 91 21:31:46 GMT References: <488@eiffel.UUCP> <1991Jan31.185534.24530@Think.COM> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 46 In article tynor@hydra.gatech.edu (Steve Tynor) writes: >>From: barmar@think.com (Barry Margolin) >... >>that RECTANGLE inherits from POLYGON. Override add_vertex in the RECTANGLE >>class with a function that reports an error. >The problem with this sort of solution is that it defers detection of the error >until run-time. It is very difficult to statically examine your code to Isn't that what I said? Here's the first paragraph of the posting you quoted above: >>If static type checking is a requirement, I believe you are right. >>However, in OO systems with dynamic type checking and method dispatch, >>there is another solution: Also, do you have any response to my point that the programmer will have to contort his program so that it is possible to statically determine that it meets all type constraints? Maybe it's my Lisp upbringing, but I believe that programs that make good use of OO are hard to write in such a way that they can be statically type-checked, unless you implement extreme restrictions (such as disallowing assigning derived class instances to ancestor class variables, i.e. the original solution 3). I didn't say it explicitly in my previous post, but I think solution 4 (allow assigning p=r, but have the compiler try to check that there are no code paths that would result in RECTANGLE::add_vertex being called) essentially forces the programmer to code as if solution 3 (disallowing the assignment) were used in many real-world applications. The program must somehow remember that not all POLYGON operations can be performed on p after such an assignment. But POLYGON has no idea which of its methods some derived class might someday disallow, so it must assume any of them may be disallowed; in this case, why bother assigning to p at all? I suppose you could assume that most methods won't be disallowed, and wait until the compiler warns you of a violation. Of course, this whole idea of performing a complete flow analysis assumes that all the information is available to the compiler. If one is deriving from a class library for which only the binary and specification are available, this will be kind of difficult, unless the binary somehow includes a useful representation of all the flow dependencies. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar