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,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.227.230 with SMTP id sd6mr10390172pbc.8.1335566551429; Fri, 27 Apr 2012 15:42:31 -0700 (PDT) MIME-Version: 1.0 Path: r9ni105972pbh.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!news.internetdienste.de!feeder.erje.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Fri, 27 Apr 2012 17:42:24 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <4f97bf40$0$6559$9b4e6d93@newsspool4.arcor-online.net> <11hojzrgyl24o$.1rbxahkuoy4ab$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1335566549 13568 69.95.181.76 (27 Apr 2012 22:42:29 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 27 Apr 2012 22:42:29 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-04-27T17:42:24-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:11hojzrgyl24o$.1rbxahkuoy4ab$.dlg@40tude.net... > On Thu, 26 Apr 2012 18:58:06 -0500, Randy Brukardt wrote: ... >> I've concluded that I'm pretty much against all forms of MI. > > Do not both Integer and Float implement "is private", T'Image, X'Size? MI > is all around you without any tagged types, you cannot get rid of it. You > sweep it under the carpet and pretend it does not exist. These examples might be "M" (multiple), but they don't represent "I" (inheritance) -- you can't (and shouldn't) inherit these things other than linearly. Note that the things that you mentioned are called "categories", "characteristics", and "aspects", respectively, in Ada. You could put them all under the unbrella of "properties", but what's important here is that the rules are necessarily different for each grouping. For instance, "categories" are not necessarily inherited, and can be view-specific (like "is private"). There is no way to unify these rules (we tried for Ada 2005 when we discovered they were poorly defined), because the needs are different. I could imagine extending the "aspect/attribute" feature to user-defined aspect/attribute pairs; that would properly mimic the idea of specific properties applying to particular types. That's all interfaces really gives you anyway, in a much more complicated way. >> Which I realize >> is probably too strong, but surely Interfaces isn't it. I'm definitely >> against any mechanism that you can only use once, which is the way a >> particular interface works. That leads to silliness like the "no hidden >> interfaces" rule (because otherwise you could destroy privacy by adding >> the >> "right" interface; alternatively, you could destroy everyone's sanity by >> determining what routine to dispatch to by what visibility you have). > > That is because the broken Java model was deployed. Look you cannot make a > type non-limited by adding "private" (=copyiable) interfaces. There is no > problem, except for fighting shadows. There are of course problems with any model, and they're a lot more than shadows. If you have a copyable interface, you of course might copy it -- so what happens if the actual object is a limited type? Runtime failures are ugly at best, and go completely against the grain of Ada's philosophy of preventing errors at compile-time. If you're willing to abandon all compile-time checking, then of course there are no problems (and probably no programs that work, either). That's not Ada. In any case, interfaces is barely compatible with Ada, and a more general scheme is impossible -- it would be completely unimplementable. You'd need to start over with a new language and new, from scratch implementations (which are not happening for Ada). Randy.