From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!usc!orion.oac.uci.edu!uci-ics!rfg
From: rfg@ics.uci.edu (Ron Guilmette)
Newsgroups: comp.lang.ada
Subject: Adding Multiple Inheritance (was: Modernizing Ada)
Message-ID: <1989Oct14.121338.1316@paris.ics.uci.edu>
Date: 14 Oct 89 19:13:38 GMT
References: <8910132028.AA07013@helios.enea.se>
Reply-To: Ron Guilmette <rfg@ics.uci.edu>
Organization: University of California, Irvine - Dept of ICS
List-Id: <comp.lang.ada>

In article <8910132028.AA07013@helios.enea.se> sommar@enea.se (Erland Sommarskog) writes:
>  It's easy to say "multiple inheritance" but it should be
>implemented too. And I'm not talking compiler technology here.
>My issue is the langauge definition. The inheritance mechanism
>should integrated with existing constructs in Ada. Say that you add
>classes a new compilation unit to Ada. Easy? Yes, but why then
>keep packages? OK, make the classes package types, but somehow
                                     ^^^^^^^^^^^^^
>I feel that we will ending up having something in the langauge
>that will be obsolete once we have a inheritance mechanism, multiple
>or not.

>All this said with the following reservation: I haven't seen
>any concrete proposal on how an inheritance mechanism in Ada
>should be look like. Therefore is my discussion on the consequences
>on such a construct somewhat hypothetical, but so is everybody
>else's too.

Well... I know that I'm definitely *not* the only one to have started to
think about how to munge MI into Ada, and I may just be putting my foot
in my mouth here, but I wonder if anybody here would like to start
discussing the pros and cons of various schemes for adding MI to Ada.

The addition of PACKAGE TYPES (kinda like task types, only different)
seems like a nice way to add the notion of CLASSES without adding another
keyword.  Seems to me like the syntax & semantics of member references
should just fall out also. If we just added a statement called "inherit"
then we would be in business. For instance:

	package type PT_1 is

		procedure FOO;

	end PT_1;

	package type PT_2 is

		type PT_2_TYPE is private;

	private

		type PT_2_TYPE is ...;

	end PT_2;

	with PT_1, PT_2;
	package type PT_3 is

		inherit PT_1 as PART_1;
		inherit PT_1 as PART_2;
		inherit PT_2 as PART_3;

		VAR : INTEGER;

		procedure MEMBER_PROC (I : INTEGER);

	end PT_3;

	procedure USE_THEM is
	begin
		THREE_VAR	: PT_3;
		WEIRD		: PT_3.PART_3.PT_2_TYPE;	-- private type

		...

		THREE_VAR.VAR := 99;

		THREE_VAR.MEMBER_PROC (99);

		THREE_VAR.PART_2.FOO := 99;

	end USE_THEM;


Any comments?
// rfg