Path: utzoo!attcan!uunet!aplcen!haven!udel!carroll
From: carroll@udel.edu (Mark Carroll <MC>)
Newsgroups: comp.lang.eiffel
Subject: Re: Inheritance and information hiding
Message-ID: <25769@nigel.udel.EDU>
Date: 27 Jul 90 01:29:12 GMT
References: <1990Jul26.221405.23439@Neon.Stanford.EDU>
Sender: usenet@ee.udel.EDU
Reply-To: carroll@udel.edu (Mark Carroll <MC>)
Organization: University of Delaware
Lines: 59

In article <1990Jul26.221405.23439@Neon.Stanford.EDU> hoelzle@Neon.Stanford.EDU (Urs Hoelzle) writes:
]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?
]

I think that you are missing something. It IS possible to check this
statically. 

If you define a taglist for each feature in the system, consisting
of the list of features called for each argument used in the proceedure,
making this a recursive process (that is, for routine A, include 
the features used directly in A, and the features used by each routine
called by A), you have a total list of features used for each argument
to the routine. When you make use of any instancye of class A, you
consult this taglist, to insure that every feature used in exported
by the class. It's certainly not easy or fast, but it is possible. (I
do not have ANY idea if this is what Eiffel does!)

]-Urs

	<MC>

--
|Mark Craig Carroll: <MC>  |"We the people want it straight for a change;
|Soon-to-be Grad Student at| cos we the people are getting tired of your games;
|University of Delaware    | If you insult us with cheap propaganda; 
|carroll@dewey.udel.edu    | We'll elect a precedent to a state of mind" -Fish