From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 20 Apr 92 16:27:24 GMT
From: dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!asuvax!ennews!enuxha.eas.a
su.edu!koehnema@ucbvax.Berkeley.EDU  (Harry Koehnemann)
Subject: Re: Ada vs. C++ Paper (was Re: Why ADA?)
Message-ID: <1992Apr20.162724.7037@ennews.eas.asu.edu>
List-Id: <comp.lang.ada>

In article <1992Apr17.211751.24319@aero.org> jordan@aero.org (Larry M. Jordan) 
writes:
>I think you are describing invoking an overridden or redefined method.
>(Please correct me if I've misunderstood.)
>The redefined method must be qualified with the class name, or one gets
>the redefining method.  Has Eiffel changed? I thought renaming was 
>done in the INHERIT clause (by the inheriting class, not the defining class). 
  
	EIFFEL					C++

class A feature func		    |	class A { Public int func; };
    ....			    |
				    |
class B feature func, a_func	    |	class B : Public A {
    Inherit A			    |		Public int func; };
	a_func renames func	    |
    ....			    |
				    |
  Have access to X.func, X.a_func   |	Have access to X.func and X.A::func
			 ^^^^^^^^				  ^^^^^^^^^

Forgive the syntax.
The user of B should only know what features B offers, not how they are
being offered.  In C++, one is forced to include the class name A in any
reference to A's func through class B.  This means that if this relationship
between B and A changes, anyone using B will need to be modified as well.
This does not sit well with information hiding.  Multiple inheritance makes
these problems even worse - what happens when a class C inherits fomr A and
B, and then defines it's own func.  This type of renaming w/ multiple
inheritance led to internal compiler errors in the Eiffel compiler I used.

Really it seems as if people aren't worrying about defining the semantics
behind inheritance and simply patching their languages as problems crop
up.  IMO, that's what C++ did with the name visibility problem described
above and it's really a horrible solution.  Some might call this the
evolutionary approach to language design, but it looks more like patching
to me.  Eiffel appears to be an excellent example of design by patching.

>Does Ada "violate information hiding...", since a name can "propogate out 
>of a [package] with more than one meaning"?   

Ada has overloading, Eiffel doesn't.  Naming in Ada is not simply a name,
but also a profile or class of object (type, constant, ...).  Ada never
requires you to know how a package is implemented in order to use it.  If
a package B is offering a something that is actually implemented in some
package A, that relationship is transparent to the user of package B.
--
Harry Koehnemann
koehnema@enuxha.eas.asu.edu