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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1592759aa83d0d45 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-01 03:29:24 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!nntp-relay.ihug.net!ihug.co.nz!small1.nntp.aus1.giganews.com!nntp.giganews.com!nntp3.aus1.giganews.com!nntp.clear.net.nz!news.clear.net.nz.POSTED!not-for-mail NNTP-Posting-Date: Sun, 01 Jun 2003 05:29:39 -0500 From: Craig Carey Newsgroups: comp.lang.ada Subject: Re: Suggestion for Ada 200x - Interface inheritance Date: Sun, 01 Jun 2003 22:29:21 +1200 Message-ID: References: <0Pxza.699607$OV.652508@rwcrnsc54> X-Newsreader: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Customer of Mercury Telecommunications Ltd Cache-Post-Path: drone5.qsi.net.nz!unknown@tnt1-40.quicksilver.net.nz X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/) X-Original-NNTP-Posting-Host: drone5-svc-skyt.qsi.net.nz X-Original-Trace: 1 Jun 2003 22:29:19 +1200, drone5-svc-skyt.qsi.net.nz NNTP-Posting-Host: 203.97.37.6 X-Trace: sv3-nYQNg4zGmrCTbDQrmDHPPsMzUeCwP43PXrQqIx4C9hAo6CosV4AuDlGXU0Za8scMtrnkySVDnnDGtLv!FpJfQqMMKUdRN8UwN7C/4hVyY+robWYCKtuL+rmfuulLxSS5oR4ifSv6wvMLyJlBypuIjR11SfAM!mkQ00ug= X-Complaints-To: Complaints to abuse@clear.net.nz X-DMCA-Complaints-To: Complaints to abuse@clear.net.nz X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:38278 Date: 2003-06-01T22:29:21+12:00 List-Id: On 23 May 2003 21:02:26 -0400, Robert A Duff wrote: >"Steve" writes: > >> Java and C# use the concept of interface inheritance. What do you think of >> adding this feature to Ada? > >I think it's a good idea. There is an AI on this, and I think the ARG >is considering it one of the most urgent ones. Look up the AI, and see >what you think. > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00251.TXT The AI contains this comment: : **************************************************************** : : From: Randy Brukardt : Sent: Monday, December 04, 2000 10:31 PM ... : I note that the proposal never seems to state that abstract interface : types must not define any components. Certainly, the implementation : model and the entire discussion seem to assume that is the case. (An : "normal" abstract type can have components defined, they'll be part of : any extension; but I don't think we want that here.) : : **************************************************************** There seems to be inherent safety in avoiding O.O. and using subrecords. So... Mulitple Inheritance is doing something like making the parent record be subrecords of the new derived type. If the aim is flatten out subrecords so that fields names can conflict and fields can be accidentally not correctly set to a value, then the flattening could be made explicit with a way to rename Ada types. Here is an example showing variable X holding 4 integers. Due to the renaming of types, the 1st Integer is identified with the name X.A instead of: X.R1.A A sample extension of Ada: ------------------------------------------------------------------------ type T1 is tagged record A, B : Integer; end record; type T2 is tagged record B, C : Integer; end record; type Mixin is tagged record R1 : <> renames T1; -- Flatten T1's fields into Mixin record R2 : T2; end record; type Mixin renames Mixin.T2; -- Flatten T2's fields into Mixin record X : Mixin := Mixin'(A => 1, R1.B => 2, R2.B => 3, C => 4); ------------------------------------------------------------------------ I regard the idea of X'Class as a way to make it easy to unintentionally leave fields not-assigned-to. It would be harder to make that mistake when there are subrecords. The "MI" gain of shifting fields of a subrecord into the surrounding containing record must be quite slight if renaming has made it look like that has occurred when it actually hadn't. Craig Carey http://www.ijs.co.nz/ada_95.htm