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, 21 Sep 2010 16:32:26 +0200 Organization: Adalog Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 21 Sep 2010 14:32:35 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="NnUeFCqNZ0jpIYDukgk1kA"; logging-data="14056"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX181YQcDIXCjtCv2tBkv0arJ" 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: Cancel-Lock: sha1:W8ptw7TGW1QLNNKlPciLrT35VrY= Xref: g2news1.google.com comp.lang.ada:14170 Date: 2010-09-21T16:32:26+02:00 List-Id: Le 21/09/2010 15:57, Cyrille a �crit : > On Sep 13, 11:13 pm, "J-P. Rosen" wrote: > >> These arguments make sense for languages without the notion of >> class-wide types. > > all OO languages I'm aware of, have the notion of classwide types... > They just don't make the distinction between a type on its own and a > type with its derived types. That's exactly what I meant: they don't have a /distinct/ notion for class-wide type. > If you think about it, it is a peculiar > distinction at the "design" level. To distinguish a node from the subtree generated by this node? Does not seem peculiar to me > A horse is an animal... When I deal > with animals, I must be ready to accept that maybe the animal I'm > dealing with may be a horse, or may be something else. It's peculiar > to expect it to be the pure notion of "animal" and nothing else... I don't understand the argument here. Clearly, "Animal" should be abstract, and you can deal only with Animal'Class. >> However, I think that redispatching can be replaced >> with class-wide operations, with great benefits from the POV of testing. > > In some cases, it may be true. Generally speaking, it is an important > to distinguish between primitive operrations and class wide > operations. They both have their use. If you are suggesting the rule > "any primitive operation that calls another primitive op of the same > type (that usually is when redispatch should occur) must be > transformed into a class-wide operation", I'm afraid this is a fierce > restriction... much fiercer than the simple dispatch rule... which > imposes one particular style of programming. No, since the class-wide operation can contain a single (re-dispatching) call. What's the gain? We have concentrated the dispatching into a single subprogram. This subprogram can be tested in isolation, and stubbed in all users. Otherwise, under the "big case" model, every user must be tested for all branches of the "big case". In a sense, it is the opposite effect of inlining. Take the arguments against inlining, you'll have the justification for this strategy. >> Cyril, will you come to the workshop? That would be very valuable. > > No, I don't plan to go. Note that on our side, we are already working > on our own set of recommendations... maybe we should try to find a > vehicle more permanent than a conference to make a community effort on > this... 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. If AdaCore has plans along the same line, by all means, send someone to the workshop (if you can't come - which I regret, since I know that you are deeply involved on this topic). -- --------------------------------------------------------- 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