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-Thread: a07f3367d7,158ce2376534c35d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!w24g2000yqw.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Derived private interface Date: Thu, 7 Jul 2011 08:10:33 -0700 (PDT) Organization: http://groups.google.com Message-ID: <1c98072b-e5b9-43dd-9fde-f6687086deef@w24g2000yqw.googlegroups.com> References: <27656578-65aa-48b9-9f89-4ebd4e0cb02a@glegroupsg2000goo.googlegroups.com> <0fe3b0f8-c064-444d-899d-640e891b58c3@w4g2000yqm.googlegroups.com> <128d8eb5-1cc6-47e3-a09b-b53a5ef289ce@m10g2000yqd.googlegroups.com> <4e141501$0$6629$9b4e6d93@newsspool2.arcor-online.net> <4b2728fc-6127-45d8-a314-9fc491701c26@g12g2000yqd.googlegroups.com> <4e145c3a$0$6542$9b4e6d93@newsspool4.arcor-online.net> <4e14dc0c$0$6565$9b4e6d93@newsspool3.arcor-online.net> <425f89e6-8c77-4615-a717-f6991ca63b65@v12g2000vby.googlegroups.com> <4e15be36$0$6556$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1310051759 11979 127.0.0.1 (7 Jul 2011 15:15:59 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 7 Jul 2011 15:15:59 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: w24g2000yqw.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20122 Date: 2011-07-07T08:10:33-07:00 List-Id: On Jul 7, 7:09=A0am, Georg Bauhaus wrote: > I guess I'm uneasy with indicators (which I use) because they > purport to solve some problem, but this is just accidental, > and ad hoc, and incomplete in several dimensions. =A0Maybe something > better is still possible. I think you're right that this was an ad hoc solution to an unforeseen problem, and that there may have been better ways to do this back in Ada 95 if the team had realized the potential problems. On the other hand, I'm not all that uneasy with it because I realize that if we waited to make sure that everything was perfect, the first version of Ada would have been Ada 2317 or something like that, and we would have been stuck with C until then. Your idea below seems sensible, but it's not backward-compatible; if it were added to the next version of Ada, a lot of legal programs would become illegal, and that's something the designers try to avoid. Perhaps there's a solution involving aspect clauses---since they're new, it would be easier to make them backward-compatible. One idea off the top of my head: type T1 is new T0 with record ... end record with inherit =3D> (Op1, Op3), override =3D> (Op2, Op4); (Aspect specifications don't currently allow lists of identifiers, but this could probably be changed compatibly.) Then the type declaration would be illegal if T0 has a primitive operation that isn't listed in either list, if an operation is listed that isn't a primitive operation of T0, if there is a conflicting declaration for something in the "inherit" list, or there is no overriding declaration for something in the "override" list. This is just a first attempt, and it definitely won't work because it doesn't deal with overloaded names and there are probably problems with private parts. But maybe we could implement your idea and still make things backward compatible: type T1 is new T0 with record ... end record with Georgs_Rules; Then if the "with Georgs_Rules" is present, the operation declarations would have to follow your rules, and if it isn't, they'd follow the old rules. Then GNAT would add an option that would cause the compiler to reject any type extension without this aspect clause. (Somebody else would have to come up with a better name for this aspect.) I'm just brainstorming here; I don't have any idea whether a feature like this would be worthwhile, particularly since it could cause the language rules to become somewhat messy. -- Adam