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: 103376,29d8139471e3f53e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!m1g2000vbh.googlegroups.com!not-for-mail From: Cyrille Newsgroups: comp.lang.ada Subject: Re: Preventing type extensions Date: Tue, 21 Sep 2010 09:18:07 -0700 (PDT) Organization: http://groups.google.com Message-ID: <81799aab-a2e8-4390-8f42-abceaa5fc032@m1g2000vbh.googlegroups.com> References: <87iq2bfenl.fsf@mid.deneb.enyo.de> <874odv9npv.fsf@ludovic-brenta.org> <87y6b7cedd.fsf@mid.deneb.enyo.de> <66a3704c-54f9-4f04-8860-aa12f516134b@t3g2000vbb.googlegroups.com> <87d3sib44t.fsf@mid.deneb.enyo.de> <134q4k2ly2pf4$.17nlv1q6q5ivo.dlg@40tude.net> <4c8dec8e$0$6990$9b4e6d93@newsspool4.arcor-online.net> <8f6cceFrv2U1@mid.individual.net> <135a7dc9-3943-45e4-884b-3cc6bce3db0a@q18g2000vbm.googlegroups.com> NNTP-Posting-Host: 212.99.106.125 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1285085887 9748 127.0.0.1 (21 Sep 2010 16:18:07 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 21 Sep 2010 16:18:07 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m1g2000vbh.googlegroups.com; posting-host=212.99.106.125; posting-account=bNhsVwoAAAB6XmNPWgYcbUm6npIwL2C4 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:14175 Date: 2010-09-21T09:18:07-07:00 List-Id: > The one that forbids redispatching in favour of class-wide operations. > This can be done only in Ada, and can be a big plus for testing. Well, I don't see anything unique to Ada in that respect except terminology. In term of capabilities with regard to dispatching, at least. > For inlining, I was referring to the corresponding chapter of OOTiA That's what I supposed.... There is little to be reused in that part of the document... > >> The workshop at the conference is the starting point for a document that > >> will define appropriate restrictions ("Fairfax profile"). Starting such > >> an effort during an Ada conference seems absolutely appropriate. > > > It seems a bit early, DO-178C hasn't been published yet and people > > participating to such an effort will need time to access it once it is > > published and understand it. > > I couldn't get my hands on DO-178C, but form what I heard it will be > based (at least on the principles) on the work of OOTiA, which > originated from the C++ community and ignores the possibilities offered > by class-wide types - that was the starting point of this thread. It is not the case. There is very little of OOTiA left in the OO supplement. It was an input to the process but the subcommittee soon realized that little could be reused. For one thing, most of the material is at the level of "coding standard" material and thus not at the right level for a standard such as DO-178.