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.68.213.106 with SMTP id nr10mr9025876pbc.2.1335528644330; Fri, 27 Apr 2012 05:10:44 -0700 (PDT) Path: r9ni104308pbh.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: Fri, 27 Apr 2012 14:10:17 +0200 Organization: cbb software GmbH Message-ID: References: <3637793.35.1335340026327.JavaMail.geo-discussion-forums@ynfi5> <9af5eaaa-1c48-4455-a8e8-39dd9ee8092d@ot8g2000pbb.googlegroups.com> <3324774.1793.1335453581565.JavaMail.geo-discussion-forums@yncc41> <21303184.864.1335494280519.JavaMail.geo-discussion-forums@pbgg10> <4f9a543a$0$6563$9b4e6d93@newsspool4.arcor-online.net> <4f9a6af0$0$6566$9b4e6d93@newsspool3.arcor-online.net> <1lxhvqsv4vrk3.151nwucj0yj15.dlg@40tude.net> <4f9a7d28$0$6565$9b4e6d93@newsspool3.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.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-27T14:10:17+02:00 List-Id: On Fri, 27 Apr 2012 13:04:08 +0200, Georg Bauhaus wrote: > On 27.04.12 12:05, Dmitry A. Kazakov wrote: >> On Fri, 27 Apr 2012 11:46:24 +0200, Georg Bauhaus wrote: >> >>> On 27.04.12 10:19, Dmitry A. Kazakov wrote: >>>> On Fri, 27 Apr 2012 10:09:31 +0200, Georg Bauhaus wrote: >>>> >>>>> On 27.04.12 04:38, ytomino wrote: >>>>> >>>>>> And, some languages such as C# has tackled the problem that a base-class >>>>>> is changed independently of derived-classes. >>>>> >>>>> Implying, maybe, that inheritance of classes may not be the >>>>> best way to write reusable modules? >>>> >>>> and the best way is? >>> >>> Starting from at least one important distinction: >>> >>> - is-a inheritance used where >>> - has-a should have been used. >> >> HAS-A to reuse modules? > > In a place A, I use the features of a module M without > introducing any of its naming issues into the facade > of A. This is not RE-use, it is just use. Reuse is when the problem domain remains same and the code is used to solve a slightly different problem it solved before. Plain use of modules obtained per inheritance imposes no problem whatsoever, because the method these modules were obtained is usually irrelevant to the end user. >> To start with you cannot have HAS-A on subprograms >> in Ada. > > I mentioned delegate objects, Ada does not support delegation. But if it did, delegation would produce same problems as inheritance does. The problem is that there is no any problem, it is how things are. > This idea blends well, I think, with the subprogram > types that you have mentioned. Meaning that subprograms > are in fact objects. First class subprogram might in the end be incompatible with strong typing. Typed procedures for downward closures, yes, but no further. There are of course issues with distributed programs (marshaling types, marshaling operations). > I fantasize that it does not blend well with grand unified > type theory. Not saying that this lack is any good. Quite possible so. I was always suspicious about functional programming paradigm for being weakly or un-typed. > To see the reason for the bias, consider "non-data type" as > a hash table because implementing "non-data type" uses > a hash table. I'd like a language to prevent this use of > IS-A, rather than encourage it. Is there such thing as a non-data type? >>> Another hint at a possibly non-best way is the STL. >> >> So the claim is that reuse of generic units does not suffer the problems >> reuse of inherited operations have? > > No. The STL does not seem to suffer, otherwise there would > be huge pressure to change it to be IS-A all over the place. Of course it does. Diamond diagram is trivial to construct with generics. In fact much of fighting with Ada generics is about resolving diamond's issues. Ada is a very poor help here. It takes incredible efforts to ensure that all actual parameters of the formal parameters of a generic are constrained to the required actuals. It is a huge pain to trace cascaded instantiations and the compile is no help. People believe that their pet methods are free of MI problems just because they never arrive at the level of complexity for problems to show. They replace MI with cut and paste. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de