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!news4.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!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: Wed, 29 Sep 2010 18:47:13 +0200 Organization: Adalog Message-ID: References: <87iq2bfenl.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> <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: Wed, 29 Sep 2010 16:47:11 +0000 (UTC) Injection-Info: mx03.eternal-september.org; posting-host="vslmL83UgSXHD8TS0/yPxA"; logging-data="27199"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Lgsfqyi+jPJc0mWBdii+n" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 In-Reply-To: <37ae2382-9f7d-4790-be5f-e380b9220d75@s19g2000vbr.googlegroups.com> Cancel-Lock: sha1:743RYfiM7Q1cymRp/f6U/bFYrBA= Xref: g2news1.google.com comp.lang.ada:14317 Date: 2010-09-29T18:47:13+02:00 List-Id: Le 24/09/2010 11:27, Cyrille a �crit : > On Sep 24, 10:39 am, Cyrille wrote: >> OK, I kind of supposed you had something like that in mind. Many years >> ago, we proposed a similar idea in a few papers, See for instancehttp://www.adacore.com/wp-content/uploads/2006/03/Certification_OO_Ad.... >> Another one written by Franco G. is even mentioned in Chelinsky's FAA >> study on OO (seehttp://www.tc.faa.gov/its/worldpac/techrpt/ar0717.pdf). >> The study is worth reading by the way... We had more automatic >> translation in mind at the time but the idea is the same. >> doing this Thanks for the pointers, but they seem to be quite close to what I am suggesting > Suggesting to do such a transformation manually at the source code > level as you do is particularly dubious since it is in the category of > program transformations whose only purpose is to circumvent specific > verifications. 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", i.e. an abstract operation that is implemented in different ways by different objects belonging to a class; i.e. all drawable objects have a "paint" method, but each objet has its own way, its own /method/, of painting itself. Since this is closely linked to a single member of a class, there is no reason to redispatch in such a method. 2) There is often a need to provide higher level operations, that are /not/ methods, but that are generally implemented by a combination of methods: Move=Erase, change position, Draw. Having these as class-wide operations rather than redispatching methods guarantees that the same behaviour is obtained for all members of the class. 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. 4) (this is the topic of my previous messages) If in some cases there is a real need for redispatching, it is still possible to follow this pattern by subcontracting the dispatching to a class-wide operation that does nothing else. But this should be a rare exception. There is no question of cheating, or maybe you consider that the patterns for programming under the Ravenscar profile are a way of cheating with the restrictions. The idea here is the same: provide a well defined pattern to ease certification. In some cases this pattern will make things more difficult? Sure. Everything is simpler if you don't need certification ;-) Note that this is quite close to Franco's approach, except that I don't rely on a specific implementation, thus preserving portability. [...] > 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. The benefit of class-wide operations is that they are easily recognizable, and therefore my proposed pattern is easily checkable by tools (read: will appear in AdaControl as soon as I get around to it). I don't think it would be as easy in other languages to ensure that the profile is followed. -- --------------------------------------------------------- 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