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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a218418d0394661d X-Google-Attributes: gid103376,public From: "Matthew Heaney" Subject: Re: Extended revelation Date: 2000/01/31 Message-ID: #1/1 X-Deja-AN: 580200683 Content-transfer-encoding: 7bit References: <873q03$alb$1@nnrp1.deja.com> <87446a$h6u$1@nnrp1.deja.com> Content-Type: text/plain; charset="US-ASCII" X-ELN-Date: Mon Jan 31 08:51:39 2000 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 949337498 38.26.192.104 (Mon, 31 Jan 2000 08:51:38 PST) Organization: EarthLink Network, Inc. Mime-version: 1.0 NNTP-Posting-Date: Mon, 31 Jan 2000 08:51:38 PST Newsgroups: comp.lang.ada Date: 2000-01-31T00:00:00+00:00 List-Id: In article <87446a$h6u$1@nnrp1.deja.com> , Jean-Marc Bourguet wrote: > I think indeed you have not understood what I want to do. What I really > want is something like modula-3 partial revelation: one package > providing multiples interface. In Ada95, a package has two interfaces, > one for the general public, one for his children. What I want is > multiple public interfaces. Until now, using child package has > permetted me to do this cleanly and here is the first example I come > with where I do not find a clean solution in Ada. Indeed I still don't know what you want to do. (Perhaps this is because I am unfamiliar with Modula-3.) Will static polymorphism work? package P1 is type T is private; procedure Op (O : in out T); ... end P1; package P2 is type T is private; type Op (O : in out T); ... end P2; If you want "multiple public interfaces," then why not implement "multiple public interfaces"? That is, different abstractions with identical public parts. If you want to statically bind to the "virtual abstraction" reified by P1 and P2, then use library-level package renaming: with P1; package P renames P1; or with P2; package P renames P2; Clients of "abstract" package P don't know or care which "concrete" package is used to implement P. That's how to handle it on the supplier side. Another way is to use "implementation inheritance," and import the type as generic formal parameters: generic type T is private; with procedure Op (O : in out T) is <>; package Generic_Client is ...; To make a client, you just supply any type with a matching profile: with P1; use P1; package Client is new Generic_Client (T); or with P2; use P2; package Client is new Generic_Client (T); But I'm only guessing what it is you're trying to do. Perhaps if you provide a small amount of code, then we can give you more specific help to solve your problem.