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,81bb2ce65a3240c3 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.156.199 with SMTP id y7mr1582599bkw.7.1335599639602; Sat, 28 Apr 2012 00:53:59 -0700 (PDT) Path: h15ni174493bkw.0!nntp.google.com!news1.google.com!goblin3!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: What would you like in Ada202X? Date: Sat, 28 Apr 2012 09:53:45 +0200 Organization: cbb software GmbH Message-ID: <19h14pweusucs$.1q59fpys2663d.dlg@40tude.net> References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <4f97bf40$0$6559$9b4e6d93@newsspool4.arcor-online.net> <11hojzrgyl24o$.1rbxahkuoy4ab$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: Gbl624r6iuNIccy3ASy5ag.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-04-28T09:53:45+02:00 List-Id: On Fri, 27 Apr 2012 17:42:24 -0500, Randy Brukardt wrote: > "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. You inherit interface here. > Note that the things that you mentioned are called "categories", > "characteristics", and "aspects", respectively, in Ada. This is only a game of words. However you name it, it will have all properties of MI. > 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"). You cannot inherit a category. Category = class. You can belong to a category or not. Inheritance is nothing but a proposition that some T belongs to some class (category). This means that it has characteristics, properties, attributes of members from the class = implements the interface of the class. MI is nothing but an ability for T to participate in more than just one class. > 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. Maybe, because desire to do it was not that pressing? > 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. In a typed way, you mean? Ad-hocery never pays off. >>> 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? Limited types do not implement that interface per definition. When you inherit both from "limited private" and from "private" you have a conflict to resolve. Ada does this using a set of hand-written rules which readers of RM certainly enjoy. This is an example of a MI problem which exists without MI being named, for which Javaesque interfaces have no answer. > 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. No, I want exactly the opposite. I want interfaces checked statically. You cannot do this without manifesting them up-front. You cannot do that without MI, because any type implements a whole of bunch of various interfaces. I want them declared. > In any case, interfaces is barely compatible with Ada, and a more general > scheme is impossible -- it would be completely unimplementable. So long there is no desire to do this, yes. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de