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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: class wide iterable (and indexable) Date: Sun, 6 Jan 2019 15:13:41 +0100 Organization: Aioe.org NNTP Server Message-ID: 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> NNTP-Posting-Host: i065DRYuysvTI4qVnaNkyg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader01.eternal-september.org comp.lang.ada:55221 Date: 2019-01-06T15:13:41+01:00 List-Id: On 2019-01-06 14:18, George Shapovalov wrote: > 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 >> 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 generally accepted (by now) OOP composition paradigm. Another, and perhaps even more essential is that that non-functionality is two-fold: > 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. 3. Constraints. Interfaces cannot have discriminants. > 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 layout through up-front often saving much grief later. Moreover, lookup collision 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 reason to keep it as is. As such, reserved word "interface" would stand for an abstract type without actual data but with inheritable primitives. Not only this would satisfy many (more) opponents, but it would provide a more complete set coverage of "problem decomposition scenarios".. There is no difference between operations and record members except than language design faults/artifacts. Publicly visible record members should have been overridable as other operations are. Same applies to the attributes. (This could not be done in Ada 83, which is the only excuse) Any problem with visibility equally applies to both. Note also that any so small problem becomes a nightmare when generics come into play. A honest macro does not have any of this because it simply expands whatever garbage into the source. Ada 83 tried to make generic expansions a more safe and this, generates mountains of problems in each language corner. Basically, this is a fine reason to reject whatever language change - oh, dear, what if this appears in a generic?.. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de