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!news4.google.com!feeder.news-service.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 15 Sep 2010 22:47:51 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; 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> <4c8f4833$0$6763$9b4e6d93@newsspool3.arcor-online.net> <2ka8sfdvyvil.1k714obgzgj3a.dlg@40tude.net> <4c8fe6ad$0$6759$9b4e6d93@newsspool3.arcor-online.net> <1dd5fjdnyl5ek.1ju0bvot51loy.dlg@40tude.net> In-Reply-To: <1dd5fjdnyl5ek.1ju0bvot51loy.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4c9130f6$0$7656$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 15 Sep 2010 22:47:50 CEST NNTP-Posting-Host: 008ebf3f.newsspool1.arcor-online.net X-Trace: DXC=SGMoJJFBa@\@>[RYkFXOIPic==]BZ:af^4Fo<]lROoRQ<`=YMgDjhgR`^X5QCGVNoSPCY\c7>ejVX?k^FGVcmmdQn;OBlMlkEH] X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:14094 Date: 2010-09-15T22:47:50+02:00 List-Id: On 9/15/10 10:15 AM, Dmitry A. Kazakov wrote: > On Tue, 14 Sep 2010 23:18:36 +0200, Georg Bauhaus wrote: >>> Hmm, how "trustworthiness" corresponds to correctness and type safety? >> 1 - Technically, [...] >> But the parent type's "plan" might require that the type's operations >> be called in a certain order, > > This is poor design. Certainly, and a "plan" suffices as an example, if you agree that perfect technical specifications of what (again, just for the sake of an example) a type writer expects an extension writer to do are not always possible. (Which I understand you do.) >> How do you talk about this on site? Can you trust the plug-in code? >> Suppose you don't use Ada, but Python or some other more dynamically >> typed language. Can you even assume the type has the same interface >> as its parent? When the absence of a statically known interface >> destroys all hope for type safety, how can programmers sill trust >> Google to continue providing meaningful Python objects for Google >> App Engine? > > This is an unrelated issue. The issue is related to trust, and to type extension, and it is an existing challenge. Call it poor design on the part of Python framework writers, if that is what it seems to be. But since the framework exists as a foundation for real software, it does affect multi-party work. We can't always control the parent types, and must see if we can find it trustworthy. >> The conflict here is triggered by a malfunctioning program: >> who/what is to blame when a type extension (by party X) does not >> work nicely with a partial program (by party Y)? > > Any software/hardware decomposition has this problem. Yes. The composition problems are varied, though. One language can offer more help than another. > The program semantics cannot be specified exhaustively. I don't know were > you want to go, but it is not only impossible to specify all program > semantics, moreover, it is also impossible to have LSP subtyping. > Substitutability in the context of subtyping cannot be upheld statically. > You have to verify substitutability per each case of substitution. > > Since we trust you, we do not verify it. Is it what you consider as > "trustworthiness"? Non-contracted behavior? More inclusively, a mix of technical and social properties of a software situation will lead to more or less trust. "Contract" is a highly overloaded term, I must refuse to use it in this context, since I cannot refer to just some isolated technical set of definitions but must include rules relevant to program production and use. Georg