Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!shelby!neon!hoelzle
From: hoelzle@Neon.Stanford.EDU (Urs Hoelzle)
Newsgroups: comp.lang.eiffel
Subject: Inheritance and information hiding
Message-ID: <1990Jul26.221405.23439@Neon.Stanford.EDU>
Date: 26 Jul 90 22:14:05 GMT
Organization: Computer Science Department, Stanford University
Lines: 36

While reading Meyer's OOSC I stumbled over this (section 11.5,
"Inheritance and Information Hiding"):

   "The Eiffel answer is quite simple [..] the two mechanisms are
    completely orthogonal."

I can see how you can claim this in a dynamically-typed language, but
I don't understand what `Information Hiding (IH)' means in a
statically typed language like Eiffel if the two mechanisms
(inheritance and IH) are indeed orthogonal.  IMHO you can no longer
(statically, i.e. at compile time) enforce IH in this case.

Consider this:

    class A  exports feature f
    class B  (a subclass of A) does not export f

That is, if a is of type A and B of type B, a.f is legal, but b.f is
not.  Now consider a code sequence such as

    a := <some expression yielding a value of type A *or* B>;
    a.f

The invocation of feature f is *only* legal if the object pointed to
by a is actually an instance of class A.  If it were an instance of
class B, we would illegally invoke a "hidden" feature, violating the
contract metaphor and the assertion system.

It is certainly possible to check for this at run time but not at
compile time.  That is, given the assumption that inheritance and IH
are orthogonal, IH semantics cannot be enforced statically.  In fact,
Eiffel is not type-safe if we consider IH violations to be type errors.

Am I missing something or is this indeed a problem?

-Urs