Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!pa.dec.com!decwrl.dec.com!joel From: joel@decwrl.dec.com (Joel McCormack) Newsgroups: comp.lang.eiffel Subject: Re: Inheritance and Information Hiding Message-ID: <1991Jan31.142545@decwrl.dec.com> Date: 31 Jan 91 22:25:45 GMT References: <10612@pasteur.Berkeley.EDU> <485@eiffel.UUCP> <488@eiffel.UUCP> Sender: news@pa.dec.com (News) Reply-To: joel@decwrl.dec.com Organization: DEC Western Research Laboratory Lines: 18 >that RECTANGLE inherits from POLYGON. Override add_vertex in the RECTANGLE >class with a function that reports an error. Permit polymorphic >assignments of the form p=r, and accept the fact that it is possible for >p.add_vertex(...) to signal an error at runtime. This is not a realistic >solution in a language without a decent exception handling mechanism, but >that's an excuse for adding exception handling, not for crippling programs. 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 determine whether your program will fail (you have to do a dataflow analysis which is hard in general). Note that the current Eiffel solution, which is to detect a type error only when given a specific system of modules, has the same problem if dynamic loading of modules is allowed--the error cannot be detected until runtime. You can detect the inconsistency at the time you try to load the module, but this may be hours or days into running the program. The user interface editor is a particularly good example: you'd like to be able to write an extendable editor that can deal with subclassess it has never se en, merely by naming them rather than linking against them. Note that dynamic loading creates other similar problems in trying to defer decisions until a ``system'' of modules is known, because the system of modules is open-ended. You can't do global register allocation, you can't defer decisions about what methods can be inlined, etc. - Joel McCormack (decwrl!joel, joel@decwrl.dec.com)