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!news3.google.com!proxad.net!feeder1-2.proxad.net!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 14 Sep 2010 12:02:28 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Securing type extensions 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> <4c8e3f44$0$6769$9b4e6d93@newsspool3.arcor-online.net> <4c8e87f8$0$6877$9b4e6d93@newsspool2.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4c8f4833$0$6763$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 14 Sep 2010 12:02:27 CEST NNTP-Posting-Host: 97acc1f0.newsspool3.arcor-online.net X-Trace: DXC=Vjl6[Zn;82oOKO]LCQ@0g`McF=Q^Z^V3h4Fo<]lROoRa8kFjLh>_cHTX3jmiS=eVX??]gc X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:14070 Date: 2010-09-14T12:02:27+02:00 List-Id: On 13.09.10 22:41, Dmitry A. Kazakov wrote: > On Mon, 13 Sep 2010 22:22:30 +0200, Georg Bauhaus wrote: > >> Yes, exactly, the design decision to declare a publicly tagged >> type (which of course will not be "final") entails mutual obligations: >> my calls on overridden subprograms will rely on profiles and further >> assumptions about overridden ops >> (such as the LSP that has been mentioned), as do the overriding >> ops of the user defined type. This kind of mutual >> trust is unrelated to Ada's visibility rules. > > Of course it is. You have to see the operation as primitive, you have to > see the object class-wide in order to dispatch. I'm asking about visibility and how it can possibly help ascertaining that user supplied subprograms are trustworthy---which is, by definition, not the same thing as "safe". E.g., "I trust this instance of Unchecked_Conversion, because ...". I don't think visibility alone can establish trust. So I'm speaking about trust and operations not known yet, in the presence of user extensible types. (And not about final types, one reason for changing the subject line.) Your_Overriding (My_T'Class (Some_Object)); Some_Object is of a type that may not exist yet when I write the body surrounding the above. Does this qualify as redispatching as seen on p.315 of Barnes (2006), or on p.545 of Cohen (1996)? If so, what is the foundation of trust in this O-O style callback scenario? I think it is a socio-economic issue, interpersonal. Client and supplier must agree that their subprograms will call each other properly (by socio-economic rules, which are not just implied by static properties of partial programs). How can Ada's visibility rules alone warrant this particular kind of trust in the case of a deliberately extensible type? IOW, how can visibility convince anyone that Your_Overriding is going to be trustworthy? If Your_Overriding is to be rules out as a design pattern, what is the alternative? I'm asking for the degree to which Ada's ___, ___, ... can establish trust. That's not the same thing as those purely mechanical static safety properties of programs. It is what human parties rely on when calling user supplied prim ops with LSP enacted in some event driven parser, for example. Georg