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.211.136 with SMTP id nc8mr4400786pbc.6.1335484211162; Thu, 26 Apr 2012 16:50:11 -0700 (PDT) MIME-Version: 1.0 Path: r9ni102352pbh.0!nntp.google.com!news2.google.com!goblin3!goblin1!goblin2!goblin.stu.neva.ru!weretis.net!feeder4.news.weretis.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: Thu, 26 Apr 2012 18:50:07 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1335484209 2307 69.95.181.76 (26 Apr 2012 23:50:09 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 26 Apr 2012 23:50:09 +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-26T18:50:07-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:w94h61g5wpzn.a60iwvyn0g83$.dlg@40tude.net... > On Wed, 25 Apr 2012 21:08:06 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:mdgi0fhwon01$.18b871w98pjl6.dlg@40tude.net... >> ... >>> There is no means to flatten P making declarations of Q be directly >>> visible >>> for clients of P. E.g. something like >>> >>> package P is >>> package Q is new Foo (...); >>> use all Q; -- Make things from Q declared directly in P >>> end P; >> >> We tried to do this for Ada 2012; we made heroic efforts to do so. The >> problem is, this feature is a massive potential maintenance problem which >> destroys most of the Ada concepts of visibility and maintainablity. (It's >> all of the mistakes of package "use" multiplied a hundred-fold.) >> >> The biggest problem comes when there is a conflict between things >> declared >> in P and things declared in Q. Resolving that proved impossible without >> introducing major headaches. > > Certainly there must be a generic mechanism for handling this. Because the > same issue arises with MI. Right, MI definitely has similar problems. Indeed, inheritance in general (no 'M' needed) has similar issues. But there are two mitigating factors that help cause the problems to be hidden in inheritance cases: (1) If the underlying package never gets maintained, problems caused by maintenance are irrelevant. The easy way to see that is to compare a package use clause given on Ada.Text_IO versus some under-development package. Text_IO changes only when a new compiler version is installed, and usually not even then (it really only changes when the language version does). In those cases, the issues caused by the new version greatly outweighs any issues caused by package use, and thus the effect is unnoticable. OTOH, if you have an actively developed package specification, changes are frequent, and errors caused by those changes on unrelated code become a significant effect (and drag on productivity). I suspect that you seem similar effects based on how much the root type changes. (2) Ada uses "cancelation" to avoid so-called Beaujolias effects, where a change causes one legal program to morph into a different legal program. Cancelation is contained for overloadable entities (the profiles have to match, which is not very likely, and suggests a definitional problem if routines with different meaning but the same name and profile exist), but for non-overloadable things (objects, types, exceptions, packages), anything with the same name is canceled, which causes a wide net of damage. Inheritance only involves overloadable entities in Ada, so the damage is greatly contained in that case. I tried to suggest making objects overloadable as a mitigation to the maintenance problems (I don't think we can ever do better than that; at some point it has to be the case that entities that are too similar are not considered "unrelated"). But that of course added a whole 'nother level of complexity to the proposal, and of course it doesn't do anything for types and packages. > Probably something really revolutionary is needed here, something like > introduction of T'Class was, which resolved all OO mess just per finger > snap. Not that revolutionary, not for Ada -- overload everything. Most languages can only overload on parameters, which is way insufficient (objects usually don't have parameters, and having all objects the same fixes nothing), but of course Ada can. The problem is mostly one of compatibility; secondarily, I don't see a good way to have overloaded types (exceptions aren't a problem; they're just objects of a built-in type; not sure about packages - package types would do the trick, but seem way over the top). Probably this would have to wait for Ada-prime (or perhaps Bob Duff's language :-). Randy.