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 Path: g2news1.google.com!postnews.google.com!26g2000yqv.googlegroups.com!not-for-mail From: Cyrille Newsgroups: comp.lang.ada Subject: Re: Preventing type extensions Date: Fri, 8 Oct 2010 06:58:14 -0700 (PDT) Organization: http://groups.google.com Message-ID: <170a6a4f-d441-4f86-8fbf-8f15da34a094@26g2000yqv.googlegroups.com> References: <87iq2bfenl.fsf@mid.deneb.enyo.de> <81799aab-a2e8-4390-8f42-abceaa5fc032@m1g2000vbh.googlegroups.com> <5c0d7798-ba09-4bd0-a28f-f1b028cce927@y3g2000vbm.googlegroups.com> <9df21c09-f611-4088-811c-c092452adffc@e20g2000vbn.googlegroups.com> <37ae2382-9f7d-4790-be5f-e380b9220d75@s19g2000vbr.googlegroups.com> NNTP-Posting-Host: 212.99.106.125 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1286563187 31005 127.0.0.1 (8 Oct 2010 18:39:47 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 8 Oct 2010 18:39:47 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 26g2000yqv.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:14437 Date: 2010-10-08T06:58:14-07:00 List-Id: On Oct 5, 7:02=A0pm, "J-P. Rosen" wrote: > Not that fast. You gave convincing examples of that position. I gave (in > my tutorial) convincing examples where redispatching is definitely not > what you want. Well, "not what you want" is not a criteria for me. The issue is clearly identified vulnerabilities. Vulnerabilities related to using method overriding and static dispatch are known and discussed in the literature. > My position here is that when redispatching is desired, in most cases, > there is a natural class-wide operation that could handle it. Often > enough to make it a general rule. Let me have some doubts... class-wide operations exist in all OO languages I'm aware of and if there was such a method, it would be peculiar that nobody had developed it in the standard OO literature in the last 30 or 40 years... Note that you use the term redispatching which I'm not too sure what it means. I'm talking more generally about static dispatch vs dynamic dispatch in the context of a class hierarchy with method overriding. > Since DO-178C is not currently publicly available, I'd be delighted to > have pointers about those "new ways" (if they are different from the > other approaches of OOTiA). Or better, come to the workshop! There will be (parts of) presentations on that topic at the "certification together" conference (http://www.certification-together.com/index.php? option=3Dcom_content&view=3Darticle&id=3D73&Itemid=3D80) > > but all this line of reasoning has been overtaken by events. Once > > again, "pessimistic" testing is not the preferred way to address the > > new objective. So trying to make "pessimistic" testing less painful is > > just not that interesting anymore. > > Hmmm... pessimistic testing is certainly impractical for C++, but I > wonder if it applies to Ada as well. I don't see any reason to see a difference between Ada and C++ in that respect. > >> To conclude about differentiating T and T'Class, the trick you suggest > >>> here is easily implementable in other OO languages. There is nothing > >>> magic in creating a wrapper around a given dispatching call and use > >>> this wrapper at each dispatch point. > > Not at all, in other languages either a subprogram is a method (part of > the dispatch table), or it applies to a single type. Class-wide > operations are not dispatched, but still can be applied to a whole > hierarchy. OK, I dismiss "void *" parameters... Looks to me this is the other way around. for instance, in C++ either a subprogram is a method or it is what you call a class-wide operation. That is to say, when your subprogram has a (ref) parameter of class C, you can pass it an object of any subclass of C and natural calls to method of that object will dispatch to the appropriate one. Note also that C++ offers a choice between static dispatch and dynamic dispatch. My C++ is a bit rusty but here is an example of that. In this program "subp" is your classwide operation. Here is the output of the program: dispatching to m 1 not dispatching to C1::m 1 dispatching to m 3 not dispatching to C1::m 2 ----------- #include using namespace std; class C1 { public: virtual int m() {return a;} C1 () { a =3D 1; } int a; }; class C2: public C1 { public: virtual int m() {return b;} C2 () { a =3D 2; b =3D 3;} int b; }; void Subp (C1 &c) { cout << "dispatching to m " << c.m() << endl; cout << "not dispatching to C1::m " << c.C1::m () << endl; } int main () { C1 c1; C2 c2; Subp (c1); Subp (c2); }