* Extended revelation @ 2000-01-31 0:00 Jean-Marc Bourguet 2000-01-31 0:00 ` Mark Lundquist ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Jean-Marc Bourguet @ 2000-01-31 0:00 UTC (permalink / raw) Hi all, I've a package which export to his users some usefull types and routines. In his private part, I've some more declarations which are exported to his child packages. My problem is that in one of the child package, I'd like to make public one of the private type (T). I had though that type T1 is private; private subtype T1 is T; but that's not valid. As renanimg does not apply to types I can't see an easy way to do it. Currently I'm using type T1 is private; private type T1 is new T; I've also considered exporting T from the parent package, but neither solution please me. -- Jean-Marc Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Extended revelation 2000-01-31 0:00 Extended revelation Jean-Marc Bourguet @ 2000-01-31 0:00 ` Mark Lundquist 2000-01-31 0:00 ` Matthew Heaney 2000-01-31 0:00 ` Jean-Marc Bourguet 2 siblings, 0 replies; 7+ messages in thread From: Mark Lundquist @ 2000-01-31 0:00 UTC (permalink / raw) Jean-Marc Bourguet wrote: > Hi all, > > I've a package which export to his users some usefull types and > routines. In his private part, I've some more declarations > which are exported to his child packages. > > My problem is that in one of the child package, I'd like to make > public one of the private type (T). That is, you want to export the type. Its definition would remain private, of course... > I had though that > > type T1 is private; > private > subtype T1 is T; > > but that's not valid. Right. A subtype declaration doesn't complete a private type declaration. > As renanimg does not apply to types I can't see > an easy way to do it. Currently I'm using > > type T1 is private; > private > type T1 is new T; > > > I've also considered exporting T from the parent package, but neither > solution please me. You're right, privately deriving T1 from T does seem crummy (for one thing, none of T's primitive operations will be publicly visible for T1...) It kind of seems like simply making T visible (still private) in the parent package is what you want to do. What do you find objectionable about that? If it "feels" right for T to be exported from the child package rather than the parent, why not move the definition of T to the child package?!? Since T is already private in the parent, I know you do not have any other declarations in the visible part of the parent that depend on the (full) definition of T. Did you know that the body of the parent can say "with Parent.Child;"? If you have declarations in the private part of the parent that require the full definition of T, then perhaps you could solve it by moving those declarations to a private child...? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Extended revelation 2000-01-31 0:00 Extended revelation Jean-Marc Bourguet 2000-01-31 0:00 ` Mark Lundquist @ 2000-01-31 0:00 ` Matthew Heaney 2000-01-31 0:00 ` Jean-Marc Bourguet 2 siblings, 0 replies; 7+ messages in thread From: Matthew Heaney @ 2000-01-31 0:00 UTC (permalink / raw) In article <873q03$alb$1@nnrp1.deja.com> , Jean-Marc Bourguet <bourguet@my-deja.com> wrote: > My problem is that in one of the child package, I'd like to make > public one of the private type (T). I had though that > > type T1 is private; > private > subtype T1 is T; > > but that's not valid. No, you can't implement the full view of a private type as a subtype. > As renanimg does not apply to types I can't see > an easy way to do it. Currently I'm using > > type T1 is private; > private > type T1 is new T; Yes, this is one way to do it. One issue with this solution is that there's no clean separation between public and private namespaces. That is, certain (usually predefined) operations can become directly visible at the point of declaration of the full view (here, T), and they may conflict with operations declared for the partial view. The best thing to do is always implement the full view of a private type as a record: package P is type T1 is private; private type T1 is record O : T; end record; end P; Now there is no problem. Indeed, I consider it a design flaw in the language, in that it allows you to implement the full view as something other than a record. I wish they had designed Ada83 private types the same way they designed Ada95 tagged types. > I've also considered exporting T from the parent package, but neither > solution please me. I'm not sure what you mean by this. Matt ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Extended revelation 2000-01-31 0:00 Extended revelation Jean-Marc Bourguet 2000-01-31 0:00 ` Mark Lundquist 2000-01-31 0:00 ` Matthew Heaney @ 2000-01-31 0:00 ` Jean-Marc Bourguet 2000-01-31 0:00 ` Matthew Heaney 2000-02-01 0:00 ` Richard D Riehle 2 siblings, 2 replies; 7+ messages in thread From: Jean-Marc Bourguet @ 2000-01-31 0:00 UTC (permalink / raw) > From: "Matthew Heaney" <matthew_heaney@acm.org> > Subject: Re: Extended revelation > Date: Mon, 31 Jan 2000 12:54:23 GMT > Organization: EarthLink Network, Inc. > > I've also considered exporting T from the parent package, but > > neither > > solution please me. > > I'm not sure what you mean by this. 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. -- Jean-Marc Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Extended revelation 2000-01-31 0:00 ` Jean-Marc Bourguet @ 2000-01-31 0:00 ` Matthew Heaney 2000-01-31 0:00 ` Vladimir Olensky 2000-02-01 0:00 ` Richard D Riehle 1 sibling, 1 reply; 7+ messages in thread From: Matthew Heaney @ 2000-01-31 0:00 UTC (permalink / raw) In article <87446a$h6u$1@nnrp1.deja.com> , Jean-Marc Bourguet <bourguet@my-deja.com> 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Extended revelation 2000-01-31 0:00 ` Matthew Heaney @ 2000-01-31 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 7+ messages in thread From: Vladimir Olensky @ 2000-01-31 0:00 UTC (permalink / raw) Matthew Heaney wrote in message ... >In article <87446a$h6u$1@nnrp1.deja.com> , Jean-Marc Bourguet ><bourguet@my-deja.com> 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.) You may want to read the article "Partial Revelation and Modula-3" at: http://www.research.digital.com/SRC/modula-3/html/partial-rev/index.html I think after reading it the intent of Jean-Marc Bourguet will be clear to you. M3 language definition could be found at: http://www.research.digital.com/SRC/m3defn/html/m3.html M3 home pages at www.m3.org and http://www.research.digital.com/SRC/modula-3/html/home.html Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Extended revelation 2000-01-31 0:00 ` Jean-Marc Bourguet 2000-01-31 0:00 ` Matthew Heaney @ 2000-02-01 0:00 ` Richard D Riehle 1 sibling, 0 replies; 7+ messages in thread From: Richard D Riehle @ 2000-02-01 0:00 UTC (permalink / raw) In article <87446a$h6u$1@nnrp1.deja.com>, Jean-Marc Bourguet <bourguet@my-deja.com> 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. You are correct about the excellent approach of Modula-3 in support of what some would call opaque types, a foundation mechanism for revelation. This can be done in Ada, but in a more awkward manner than in Modula-3. package P1 is type T1 is tagged private; -- other public declarations private type Data; type T1 is access Data; end P1; package body P1 is type Data is record ... end record; -- more declarations end P1; This is quite similar to the style used in Modula-2, if you remember that far back. It is similar to, but not as expressive as, the revelation mechanism in Modula-3. Sometimes we might want to make the private type extensible. package P2 is type T2 is tagged private; -- usually an abstract type -- other declarations private type Data; type Pointer is access Data; type T2 is tagged record X : Pointer; end record; end P2; This provides extensible inheritance while encapsulating all information about the Data in the implementing code. The package body will be coded to reflect the actual data. One benefit of this is the ability to acquire the data descriptions, at the implementation level, from some entirely different package, even a private child unit in the same hierarchy. In this respect, Ada has some benefits over Modula-3 in spite of its awkwardness vis a vis designing an opaque type. This goes back, again, to the issue of expressibility versus expressiveness. Modula-3 is much more expressive of opaque types than Ada. Ada is slightly more expressive of modular composition and independence than Modula-3. There is no perfect programming language. There is an upside, in expressiveness, to revelation. There is a downside in the branded reference mechanism required to support opaque types and revelation. Often, in Modula-3, an error is not discovered until link time. In Ada, every type mismatch will be caught at compile time. This may be one of those things that is seldom a problem, but it does become significant in a large scale software system consisting of lots of modules. Richard Riehle richard@adaworks.com ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-02-01 0:00 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-01-31 0:00 Extended revelation Jean-Marc Bourguet 2000-01-31 0:00 ` Mark Lundquist 2000-01-31 0:00 ` Matthew Heaney 2000-01-31 0:00 ` Jean-Marc Bourguet 2000-01-31 0:00 ` Matthew Heaney 2000-01-31 0:00 ` Vladimir Olensky 2000-02-01 0:00 ` Richard D Riehle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox