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.7 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, REPLYTO_WITHOUT_TO_CC,YOU_INHERIT autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,73f81e5f5d6ee80f X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!cyclone1.gnilink.net!gnilink.net!nx02.iad.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: MI is sloppy 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: <1g29uf1ygl1wc$.1x184o2bk9m0k$.dlg@40tude.net> Date: Fri, 12 Dec 2008 10:59:17 +0100 Message-ID: <1hjx0k7xmfw4n$.14q7chpo1r1ma$.dlg@40tude.net> NNTP-Posting-Date: 12 Dec 2008 10:59:17 CET NNTP-Posting-Host: a6696e9a.newsspool2.arcor-online.net X-Trace: DXC=H=Z>\FdTg\Hgj[ZPFj7ehOA9EHlD;3YcB4Fo<]lROoRA^YC2XCjHcbI^3QAZeYME[HDNcfSJ;bb[EFCTGGVUmh?DLK[5LiR>kgB3\H8Nfl7MhI X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:2970 Date: 2008-12-12T10:59:17+01:00 List-Id: On Thu, 11 Dec 2008 15:44:30 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1g29uf1ygl1wc$.1x184o2bk9m0k$.dlg@40tude.net... >> On Wed, 10 Dec 2008 18:40:46 -0600, Randy Brukardt wrote: > ... >>> I tend to think so. These are insufficiently different to be types; there >>> should only be one type and different subtypes. Subtypes imply runtime >>> checks, but with good contracts most such errors can still be detected by >>> tools. And you don't have the goofy restrictions that come with trying to >>> make things separate types that aren't logically separate. >> >> Huh, I don't see any difference. Semantically >> >> type Inout_File is ... >> procedure Get (File : in out Inout_File; Item : out Data); >> procedure Put (File : in out Inout_File; Item : Data); >> >> subtype In_File is ...; >> procedure Get (File : in out Input_File; Item : out Data) is abstract; >> >> subtype Out_File is ...; >> procedure Put (File : in out Output_File; Item : Data) is abstract; >> >> Whatever way you go, incrementally adding operations or else incrementally >> removing them. > > No, that's not what I meant. I meant something like: > > type File is ... > subtype Inout_File is ... > subtype In_File is ... > subtype Out_File is ... > procedure Get (A_File : in out File; Item : out Data) > with precondition A_File not in In_File; > procedure Put (A_File : in out File; Item : Data) > with precondition A_File not in Out_File; To me it is exactly same. The precondition not to be in a subtype is equivalent to disallowing the operations specific to that subtype. Unless precondition is treated as a constraint check with Constraint_Error propagated. In the latter case Get is merely an overriding by the body begin raise Constraint_Error; end; Not very exciting to me. >>.. it is a "God-class," > > Pretty much everything real ends up that way anyhow. Is there really any > need to extend a good container class? Most of the counter-examples are > acedemic cases that rarely occur in practice. (Yes, inheritance works great > for windowing GUIs. And hardly anything else. So maybe it is the GUI that is > the unusual and oddly designed case??) That is because that "else" is not built upon inheritance. Tasks aren't tagged. End of story. I honestly believe that inheritance must be given a chance. After all, there is no any other candidate. Well, there is generics. But you cannot extend/cut/attune anything with generics anyway. >> it is potentially inefficient when only input is used, >> etc. (It is not the way programs are designed, if we could pick a ready >> program from the pool of all possible programs. (:-)) > > Link-time compilation (a basic part of the overall design of Janus/Ada, just > not practical until very recently) would eliminate most of the > inefficiencies, just as it has the potential to eliminate most of the > inefficiencies of generic code sharing and defaulted parameters. But it > wouldn't put static roadblocks into your way or magic inheritance where you > need fancy tools just to figure out what operations are available for a > type. (That's surely the case with Claw.) I agree that finding the primitive operations of a type is a problem. > In any case, I think we need to see such static analysis working in > compilers before trying to mandate it. And there isn't any such at the > moment. If anyone has a half-a-million dollars that they'd like to spend on > Ada, I surely would like to try... :-) But that can be the niche where Ada could survive. Going more and more dynamic will eventually kill Ada. There is Phyton and other fancy dynamically typed languages. The niche write-once-debug-forever is densely inhabited already... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de