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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:a945:: with SMTP id x5mr6376002iti.26.1546780715521; Sun, 06 Jan 2019 05:18:35 -0800 (PST) X-Received: by 2002:a9d:6f9a:: with SMTP id h26mr1186624otq.0.1546780715259; Sun, 06 Jan 2019 05:18:35 -0800 (PST) Newsgroups: comp.lang.ada Date: Sun, 6 Jan 2019 05:18:34 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=85.168.19.89; posting-account=O_NgcgoAAABs6pgCjroQBmOBL5ZZGPUc NNTP-Posting-Host: 85.168.19.89 References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> <9e6b4219-d6ba-4c89-814d-5ea6e48ed8ea@googlegroups.com> <9179093f-4765-47a9-9dc6-147c9d7d6c56@googlegroups.com> <809a445d-cf73-4525-a732-67dbf24e8394@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: class wide iterable (and indexable) From: George Shapovalov Injection-Date: Sun, 06 Jan 2019 13:18:35 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!feed.ac-versailles.fr!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!q69no544853itb.0!news-out.google.com!v71ni537ita.0!nntp.google.com!q69no544850itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Xref: reader01.eternal-september.org comp.lang.ada:55220 Date: 2019-01-06T05:18:34-08:00 List-Id: On Sunday, January 6, 2019 at 1:45:09 PM UTC+1, Dmitry A. Kazakov wrote: > Yep, Max Planck: [..] Ah, yes indeed, thank you for the specifics, it was a while ago that I last= had to recall that :). > Yes. Interface is an abstract tagged type, nothing more except for a=20 > silly constraint not to provide anything functional. Ah, so you mean that if the "stupid nonfunctionality constraint" is removed= then there is no need to have an extra reserved word? I see. But there are= reasons beyond that. One would be readability and consistence with general= ly accepted (by now) OOP composition paradigm. Another, and perhaps even mo= re essential is that that non-functionality is two-fold:=20 1. provision of inheritable primitives, which is the really lacking feature= IMHO (and evidently in opinion of many other people), and 2. provision of data entries. The 2nd one, while useful in some situations, can usually be worked around = with proper type layout. In fact such prohibition forces to think type layo= ut through up-front often saving much grief later. Moreover, lookup collisi= on resolution rules are very often different for data and methods, quickly = causing mess of things. So I think, at least on this one there is a good re= ason to keep it as is. As such, reserved word "interface" would stand for a= n abstract type without actual data but with inheritable primitives. Not on= ly this would satisfy many (more) opponents, but it would provide a more co= mplete set coverage of "problem decomposition scenarios".. George