rfg@ics.uci.edu (Ron Guilmette) (10/15/89)
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
eberard@ajpo.sei.cmu.edu (Edward Berard) (10/15/89)
Ron Guilmette (rfg@ics.uci.edu) writes: > 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 [...] ... > > >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. [...] ... > > 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. [...] ... > [...] ... > // rfg For those of you who are interested, there is a small group of individuals who are working to formally suggest object-oriented extensions to the Ada language. They held a three-day meeting in the Boston, Mass. area during September. For more information, contact Rich Hilliard at MITRE: E-mail : rh@mbunix.mitre.org Office : The MITRE Corporation MS A155 Bedford, MA 01730 TELEPHONE : (617) 271-7760 The time for revision suggestions for Ada 9X is almost over. If you think you have any good ideas, be quick about it. -- Ed Berard (301) 353-9652
dik@cwi.nl (Dik T. Winter) (10/15/89)
In article <1989Oct14.121338.1316@paris.ics.uci.edu> Ron Guilmette <rfg@ics.uci.edu> writes:
I must be extremely dense, but what is wrong if we modify it as follows
(and get proper Ada on the fly)?
(Lines marked + are added; lines marked - are deleted.)
- package type PT_1 is
+ generic package PT_1 is
procedure FOO;
end PT_1;
- package type PT_2 is
+ generic package 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
+ generic package PT_3 is
- inherit PT_1 as PART_1;
+ PART_1 is new PT_1;
- inherit PT_1 as PART_2;
+ PART_2 is new PT_1;
- inherit PT_2 as PART_3;
+ PART_3 is new PT_2;
VAR : INTEGER;
procedure MEMBER_PROC (I : INTEGER);
end PT_3;
+ with PT3;
procedure USE_THEM is
begin
- THREE_VAR : PT_3;
+ THREE_VAR is new PT_3;
- WEIRD : PT_3.PART_3.PT_2_TYPE; -- private type
+ WEIRD : THREE_VAR.PART_3.PT_2_TYPE;
...
THREE_VAR.VAR := 99;
THREE_VAR.MEMBER_PROC (99);
THREE_VAR.PART_2.FOO := 99;
end USE_THEM;
The only distinction is that THREE_VAR is not a variable, but a package.
It is long ago that I did something with Simula-67, and also I do not
follow closely the buzz-word discussion. In any case what this proposer
attempted to get into Ada 9X is already possible in Ada 83, unless I am
very obtuse indeed.
--
dik t. winter, cwi, amsterdam, nederland
INTERNET : dik@cwi.nl
BITNET/EARN: dik@mcvaxsimpson@trwarcadia.uucp (Scott Simpson) (10/16/89)
In article <604@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: >For those of you who are interested, there is a small group of >individuals who are working to formally suggest object-oriented >extensions to the Ada language. I know of two such existing extensions already (I'm sure Ed has heard of these): Classic Ada from Software Productivity Solutions (SPS@radc-softvax.arpa). DRAGOON from a European consortium. A guy from DRAGOON came out and spoke to us. DRAGOON is targeted at distributed systems and supports assertions. I'm sure I have left some other extensions out. Scott Simpson TRW Space and Defense Sector usc!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet)