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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!feeder2.cambriumusenet.nl!feed.tweaknews.nl!194.134.4.91.MISMATCH!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!194.109.133.84.MISMATCH!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!feeder.news-service.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Securing type extensions Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> <4c9130f6$0$7656$9b4e6d93@newsspool1.arcor-online.net> <1rzqpilsu35mh.dzxeefhdmt1s.dlg@40tude.net> <4c920504$0$6767$9b4e6d93@newsspool3.arcor-online.net> Date: Thu, 16 Sep 2010 14:45:31 +0200 Message-ID: <9d43s5gucfe8.1llq6tdbd4e0h.dlg@40tude.net> NNTP-Posting-Date: 16 Sep 2010 14:45:31 CEST NNTP-Posting-Host: 9ec289b8.newsspool3.arcor-online.net X-Trace: DXC=gdPNN?[H7?cPXlQ;h]GTMdMcF=Q^Z^V3h4Fo<]lROoRa8kF On Thu, 16 Sep 2010 13:52:36 +0200, Georg Bauhaus wrote: > On 16.09.10 09:47, Dmitry A. Kazakov wrote: > >>> 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.) >> >> That is not the type writer. > > Party X made a library, L, of O-O types, abstract or not. > Party Y extends a type in L, say T > > I'm talking about how X and Y can trust each other before > X licenses the library and before Y writes an extension. They need not. > What technical factors of a language's type extension mechanism > will likely make X and Y be more confident that nothing will > go wrong? None, not needed, impossible anyway. >>> 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. >> >> and the point is? > > The point is to fathom the dark waters of software development > from multiple components, of possibly closed source: > Is there anything in Ada that acts like a flash light when > compared to more dynamic languages? Separation of interface and implementation. Strong, static, manifested typing. Static analysis. Least assumption design principle. > Facilities of Ada that makes > one feel more secure when extending a type? Classes consistently mapped onto types. > (You remember the story often told about Roman bridge builders > having to stand under their new bridge on opening day. Just to > illustrate trust.) Huh, it is the pedestrians to stay under the bridge. For the most recent example see: http://www.wired.com/threatlevel/2010/09/first-sale-doctrine/ >> The way you described it, trust has no physical meaning. > > When you sign a contract with your name, then this is quite physical. If only signatures could make programs working... > When you pay, or don't pay, this is easily measured. Measured what? Do you trust Microsoft? >> It is a >> psychological phenomenon, not a subject of CS and SW engineering. > > Psychology, politics, ambition and money are undoubtably parts of > SW engineering, steering the decisions. They are essential to > engineering in general. As a framework they are. That does not make them engineering. > This famous rocket did not have an O-ring suitable for the range of > temperatures, they say, and then it exploded. There had been some > protest before the parts were composed to form the rocket. An example > showing that engineering is not just about technical formulas. Which was a perfect example of the opposite - of how engineering was defeated by trust. They trusted in that the rocket would not explode. People used to trust in silly things. Engineers are those who do not trust. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de