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!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: T'Interface attribute Date: Sat, 5 Aug 2017 09:49:28 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.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:52.0) Gecko/20100101 Thunderbird/52.2.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:47603 Date: 2017-08-05T09:49:28+02:00 List-Id: On 2017-08-05 01:51, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:oluj7t$8uo$1@gioia.aioe.org... >> On 2017-08-03 06:46, Randy Brukardt wrote: >>> "Dmitry A. Kazakov" wrote in message >>> news:olskua$1bfd$1@gioia.aioe.org... >>>> In order to reduce name space contamination I would propose attribute >>>> T'Interface which for any tagged type T would denote an interface type >>>> with all *new* primitive operations, e.g. >>> >>> Past experience say that such attributes (that is, those that designate >>> some >>> sort of type or subtype) don't work out very well in Ada. For instance, >>> we >>> considered T'Access in Ada 2005, but gave that up because of various >>> problems (and replaced with with anonymous access types, which are >>> worse). >>> The worst problem was that there was no limit to the attribute, you could >>> write T'Access'Access'Access - and you can't prevent this since T could >>> be a >>> generic formal type that itself is some T'Access. >> >> In this case generic would not be a problem because T must be tagged to >> have T'Interface. >> >> As a side note, differently to 'Access, 'Length and actually 'Class, >> 'Interface is idempotent: >> >> T'Interface ::= T'Interface'Interface > > Ada defines 'Class this way, too, I think in part to mitigate these > problems. > > The problem with formals is from the actual being T'Interface: > > generic > type T is abstract tagged private; > package Gen is > procedure P (Item : in T'Interface); > end Gen; > > package Inst is new Gen (Some_Tagged_Type'Interface); > > The parameter of P is essentially Some_Tagged_Type'Interface'Interface. But P is not primitive. So effectively it can be compiled into procedure P (Item : in T); There is no requirement on what would evaluate this: package body Gen is function Check (X : T'Interface; Y : T) return Boolean begin return X'Tag = Y'Tag; end Check; > That suggests a problem with this idea: effectivelly all types would have an > associated interface. But interfaces can never be hidden (certainly not > without restrictions as discussed in AI12-0023-1), so that would seem to > imply that no hidden type derivations could occur. That would be a massive > compatibility problem. Yes, you mean this: type I is interface; type T is new I with null record; type S is tagged private; private type S is new T with null record; -- Illegal? Come on! This mess should be fixed someday. BTW, there is nothing wrong with hidden interfaces. There apparent problems come from an misunderstanding, IMO. There is nothing wrong with additive inheritance. The same interface when added twice once publicly once privately could simply allocate new slots. In all contexts where both become visible must require explicit name resolution, e.g. by renaming one of the types and/or primitive operations. The typical use-case is a linked list interface, when elements participate in several lists. type Linked is limited interface; function Next (Element : Linked) return Linked; ... type Triple_Queue is new Linked or Linked or Linked with ... >>> P.S. And as always, explain the problem to be solved as well as the possible >>> solution. That is always necessary to understand the value of a proposal. >> >> I have a design rule to have an explicit interface declared for each >> tagged type. It saves much of redesign later. > > I've generally materialized that as "the root of an abstraction should > always be declared abstract". Yes, but this is not enough, because it kills potential multiple-inheritance cases. > In Claw, the only places that we got much benefit from OOP (beyond > dispatching callbacks, the reason we used OOP in the first place) was in > sharing implementations across related types. But that doesn't work for Ada > interfaces, because you can't have any components in the type -- meaning > that writing real implementations is impossible. One can use abstract types > in this way (and we did so extensively). Reuse happens on the client's side, when you share interface-wide implementations. This includes helper types which refer to [access] I'Class. Surely you have lots of them to pass widgets around, in events, in handlers etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de