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!news3.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: Preventing type extensions Date: Tue, 05 Oct 2010 19:02:27 +0200 Organization: Adalog Message-ID: References: <87iq2bfenl.fsf@mid.deneb.enyo.de> <8f6cceFrv2U1@mid.individual.net> <135a7dc9-3943-45e4-884b-3cc6bce3db0a@q18g2000vbm.googlegroups.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 5 Oct 2010 17:02:24 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="vslmL83UgSXHD8TS0/yPxA"; logging-data="5663"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Yfwme2FrkwwrrOKSpRyxm" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 In-Reply-To: Cancel-Lock: sha1:BXkUCozFPYgLcClXPe4iBbjZH5o= Xref: g2news1.google.com comp.lang.ada:14398 Date: 2010-10-05T19:02:27+02:00 List-Id: Le 30/09/2010 12:08, Cyrille a �crit : >> Not at all, but I may not have clearly explained my line of reasoning. >> 1) (Most important) I think that a method should really be a "method", > sure a method should be a method. I think it won't be hard to have a > general agreement on that ;-) Well... nowadays, many people, and especially the new generation that has been fed with Java, tends to call "method" every subprogram. I meant "real methods". > if there is no reason to use the other methods of the same tagged type > in the method in question, there is no issue of redispatch anyway. if > there are such uses and they are done through non-dispatching calls, > then there are real vulnerabilities and they should be addressed. > There is no way around that. 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. 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. [...] >> 3) I propose to enforce this strict separation, with the added benefit >> that all dispatching calls are located in class-wide operations, and >> thus reduce the coverage effort. > > what coverage effort? You seem to believe that "pessimistic testing" > is mandatory... this is not the case in DO-178C as I explained in a > former post. Not mandatory, but one possible solution to coverage. [...] > The pattern you suggest (using those wrappers) doesn't address any > vulnerabilities I am aware of and doesn't help much with coverage > since there are other better ways to achieve the new related objective > in the DO-178C. 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! > 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. >> 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... ---- But my goal is not to force my particular views; the important point is whether an appropriate profile could be defined for high reliability OO Ada programs. Such a profile could give a definitive competitive advantage to Ada in that area. If you (or anyone else on this list, or even in outer space ;) ) have good ideas about what to put in that profile, by all means, come to the workshop, or make a proposal (private mail to me, I'll gather proposals). -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Adalog a d�m�nag� / Adalog has moved: 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00