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,7009541db2ced1ad X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.velia.net!news.tu-darmstadt.de!newsfeed.freenet.de!news2.euro.net!feeder4.cambrium.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng1.kpn.DE!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Construction initialization problem Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: Date: Fri, 5 Dec 2008 10:00:01 +0100 Message-ID: NNTP-Posting-Date: 05 Dec 2008 10:00:01 CET NNTP-Posting-Host: 57828155.newsspool2.arcor-online.net X-Trace: DXC=;lZP2Hj1KWL0YVY]kmLTlDA9EHlD;3YcB4Fo<]lROoRA^YC2XCjHcbIO^aBVWN2hEFDNcfSJ;bb[EFCTGGVUmh?DLK[5LiR>kgB>looNUi`hHC X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:3858 Date: 2008-12-05T10:00:01+01:00 List-Id: On Thu, 4 Dec 2008 16:17:56 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:oscmgxrpod50$.g7h7snlssha0$.dlg@40tude.net... >> Consider this: >> >> type A is tagged limited null record; >> type B (X : not null access A'Class) is tagged limited null record; >> >> Now we want to specialize B so that its instances would already contain A: > > You never explained why you would want the discriminant in the first place. Huh, that is a mix-in, a major excuse for not to have multiple inheritance in Ada! > I would think that it would be better to do what you've said about C > (include the instance directly in it) from the beginning, and the problem > doesn't come up. No, in the case I have in mind, mix-in is appropriate. Consider layered network protocols. "A" were a transport layer. "B" were a protocol. There can be many different transports for the same protocol so an implementation of B shall dispatch to the operations of A. If B would inherit to A that would require permanent conversions to A'Class inside the operations of B (=a mess). Now consider that at some point you decided which transport (some type derived from A) and which protocol (some type derived from B) to take. You want to put it all into one opaque object. That would be the type C. But you cannot, without pointers and dynamic allocation. Welcome back to C++! > Access discriminants have a fairly high overhead in Ada (because of the > possibility of coextensions), so unless you *need* coextensions, they ought > to be avoided. Do you mean space or time overhead? > One could use a named access type instead to declare the discriminant if you > really need a discriminant. You mean an access component? But because Ada has no proper construction, there is no way to use not-null access components. OK, I know and in fact use one, but it is very intrusive. > But the only time you must use a discriminant is > if you have a discriminant-dependent component, and there is no interesting > way to make a component dependent on an access discriminant. So I'd prefer > to just avoid the discriminant. > > If you're using discriminants to stand in for a proper constructor, I say > "don't!!" Use a constructor function as the language intends (and force it > with a (<>) if you need it). Oh no, been there. The problem arose from inability to write such a function! You must be able to write an aggregate to return it from the function. The components of the aggregate will have the constraints impossible to spell. ---------------------------- The language problem is lack of abstraction. If there were abstract access types, then you could make an instance of A implement the interface of "access A" and them simply put an object of A as a discriminant for B: type AA is new A and access A with null record; -- A and access to A overriding function "'Access" (X : A) return access A; function Create return AA; -- Creates an instance of AA B_with_A : B (Create); -- Constrain it by an object -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de