* Private Children @ 1999-06-20 0:00 Matthew Heaney 1999-06-21 0:00 ` Dale Stanbrough 1999-06-21 0:00 ` Ted Dennison 0 siblings, 2 replies; 22+ messages in thread From: Matthew Heaney @ 1999-06-20 0:00 UTC (permalink / raw) Can a public child package with its private sibling? According to my compiler, the answer is no. When I try to compile the unit below (P.C2), I get the following error message: gcc -c -gnatc /home/matt/p-c2.ads p-c2.ads:1:06: current unit must also be private descendant of "P" Public child P.C2 only uses the entity provided by its private sibling P.C1 in its private region. What is the rationale for making this illegal? --STX package P is pragma Pure; end P; private package P.C1 is I1 : Integer; end P.C1; with P.C1; package P.C2 is I2 : Integer; private I3 : Integer := P.C1.I1; end P.C2; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-20 0:00 Private Children Matthew Heaney @ 1999-06-21 0:00 ` Dale Stanbrough 1999-06-21 0:00 ` Ted Dennison 1 sibling, 0 replies; 22+ messages in thread From: Dale Stanbrough @ 1999-06-21 0:00 UTC (permalink / raw) Matthew Heaney wrote: " Can a public child package with its private sibling? According to my compiler, the answer is no. When I try to compile the unit below (P.C2), I get the following error message: gcc -c -gnatc /home/matt/p-c2.ads p-c2.ads:1:06: current unit must also be private descendant of "P" Public child P.C2 only uses the entity provided by its private sibling P.C1 in its private region. What is the rationale for making this illegal?" Tucker Taft once explained that this allows for "compilation privacy" (my description). This guarentees that if a private package spec changes, you don't have to do any recompilation of any public packages (just relinking). Personally I don't care for it, and would have much preferred "implementation privacy" where changes to a spec of a private package could still mean that public clients may have to be recompiled, but not updated in any other way. Dale ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-20 0:00 Private Children Matthew Heaney 1999-06-21 0:00 ` Dale Stanbrough @ 1999-06-21 0:00 ` Ted Dennison 1999-06-21 0:00 ` Tucker Taft 1999-06-25 0:00 ` Robert Dewar 1 sibling, 2 replies; 22+ messages in thread From: Ted Dennison @ 1999-06-21 0:00 UTC (permalink / raw) In article <m3bteacxb8.fsf@mheaney.ni.net>, Matthew Heaney <matthew_heaney@acm.org> wrote: > Can a public child package with its private sibling? > Almost exactly one month ago, I posted the exact same question. Go to deja.com and search for a thread titled "Children of private compilation units" to see the discussion. As I remember, it went something like this: Gnat doesn't accept it, and Robert Dewar says its not legal Ada. ObjectAda and GreenHills do accept it, and Tucker Taft says it *is* legal Ada. I offered to send in a bug report to the appropriate vendor, if a consensus could be reached on which one was in error. Currenly there appears to be no such consensus. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-21 0:00 ` Ted Dennison @ 1999-06-21 0:00 ` Tucker Taft 1999-06-21 0:00 ` Matthew Heaney 1999-06-21 0:00 ` Matthew Heaney 1999-06-25 0:00 ` Robert Dewar 1 sibling, 2 replies; 22+ messages in thread From: Tucker Taft @ 1999-06-21 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <m3bteacxb8.fsf@mheaney.ni.net>, > Matthew Heaney <matthew_heaney@acm.org> wrote: > > Can a public child package with its private sibling? > > > > Almost exactly one month ago, I posted the exact same question. > Go to deja.com and search for a thread titled "Children of private > compilation units" to see the discussion. > > As I remember, it went something like this: Gnat doesn't accept it, and > Robert Dewar says its not legal Ada. ObjectAda and GreenHills do accept > it, and Tucker Taft says it *is* legal Ada. I offered to send in a bug > report to the appropriate vendor, if a consensus could be reached on > which one was in error. Currenly there appears to be no such consensus. No, this was a different issue. It had to do with whether a specless subprogram was considered a spec or a body. Bodies are allowed to "with" private siblings, specs are not. In this case, the ultimate consensus position, based on AARM readings, is that a specless subprogram is treated like a "spec" for the purposes of this rule, and may not "with" a private sibling. To answer the question posed by this new question, the answer given by Dale was correct, that private children provide "compilation privacy." If you want to allow something to be "with"ed by public children's specs, but contain content that is only visible to the private part of the child's spec, the following idiom works: package Mostly_Private is private ... -- Declarations visible only in private part of other public ... -- siblings end Mostly_Private; That is, put the entire set of declarations in the private part of a public child. > T.E.D. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-21 0:00 ` Tucker Taft @ 1999-06-21 0:00 ` Matthew Heaney 1999-06-21 0:00 ` Matthew Heaney 1 sibling, 0 replies; 22+ messages in thread From: Matthew Heaney @ 1999-06-21 0:00 UTC (permalink / raw) On 21 Jun 1999 17:04, Tucker Taft <stt@averstar.com> wrote: > To answer the question posed by this new question, the answer > given by Dale was correct, that private children provide "compilation > privacy." If you want to allow something to be "with"ed by public > children's specs, but contain content that is only visible to > the private part of the child's spec, the following idiom works: > > package Mostly_Private is > private > ... -- Declarations visible only in private part of other public > ... -- siblings > end Mostly_Private; > > That is, put the entire set of declarations in the private part > of a public child. I did what I think you wanted me to do, but got this error message: gcc -c -gnatc /home/matt/p-c2.ads p-c2.ads:9:23: "I1" is not a visible entity of "C1" Is this a compiler bug, or did I misunderstand what you said? Can a package really see the private part of its sibling? I thought that only your own children could see your private part. Or did you mean for me to put I1 in the private part of P, not P.C1? --STX package P is pragma Pure; end P; package P.C1 is private I1 : Integer; end P.C1; with P.C1; package P.C2 is I2 : Integer; private I3 : Integer := P.C1.I1; end P.C2; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-21 0:00 ` Tucker Taft 1999-06-21 0:00 ` Matthew Heaney @ 1999-06-21 0:00 ` Matthew Heaney 1999-06-21 0:00 ` Tucker Taft 1 sibling, 1 reply; 22+ messages in thread From: Matthew Heaney @ 1999-06-21 0:00 UTC (permalink / raw) On 21 Jun 1999 17:04, Tucker Taft <stt@averstar.com> wrote: > To answer the question posed by this new question, the answer > given by Dale was correct, that private children provide "compilation > privacy." If you want to allow something to be "with"ed by public > children's specs, but contain content that is only visible to > the private part of the child's spec, the following idiom works: > > package Mostly_Private is > private > ... -- Declarations visible only in private part of other public > ... -- siblings > end Mostly_Private; > > That is, put the entire set of declarations in the private part > of a public child. I did what I think you wanted me to do, but got this error message: gcc -c -gnatc /home/matt/p-c2.ads p-c2.ads:9:23: "I1" is not a visible entity of "C1" Is this a compiler bug, or did I misunderstand what you said? Can a package really see the private part of its sibling? I thought that only your own children could see your private part. Or did you mean for me to put I1 in the private part of P, not P.C1? --STX package P is pragma Pure; end P; package P.C1 is private I1 : Integer; end P.C1; with P.C1; package P.C2 is I2 : Integer; private I3 : Integer := P.C1.I1; end P.C2; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-21 0:00 ` Matthew Heaney @ 1999-06-21 0:00 ` Tucker Taft 1999-06-22 0:00 ` Richard D Riehle 0 siblings, 1 reply; 22+ messages in thread From: Tucker Taft @ 1999-06-21 0:00 UTC (permalink / raw) Matthew Heaney wrote: > > On 21 Jun 1999 17:04, Tucker Taft <stt@averstar.com> wrote: > > > To answer the question posed by this new question, the answer > > given by Dale was correct, that private children provide "compilation > > privacy." If you want to allow something to be "with"ed by public > > children's specs, but contain content that is only visible to > > the private part of the child's spec, the following idiom works: > > > > package Mostly_Private is > > private > > ... -- Declarations visible only in private part of other public > > ... -- siblings > > end Mostly_Private; > > > > That is, put the entire set of declarations in the private part > > of a public child. > > I did what I think you wanted me to do, but got this error message: > > gcc -c -gnatc /home/matt/p-c2.ads > p-c2.ads:9:23: "I1" is not a visible entity of "C1" > > Is this a compiler bug, or did I misunderstand what you said? > > Can a package really see the private part of its sibling? I thought > that only your own children could see your private part. Oops, right you are. The "idiom" I was misremembering was actually to create an extra level in the hierarchy, with all of the public children made into public children of this intermediate level, with the intermediate level spec having only a private part. You could then use library unit renaming to hide the presence of this intermediate level, if you wanted to. I believe Robert Eachus suggested this approach originally. E.g.: package P.Hidden_Level is private ... -- private stuff end; package P.Hidden_Level.C1 is ... private ... -- can see private decls of P.Hidden_Level end; with P.Hidden_Level.C1; package P.C1 renames P.Hidden_Level.C1; Sorry for the confusion. -Tuck > Or did you mean for me to put I1 in the private part of P, not P.C1? > > --STX > package P is > > pragma Pure; > > end P; > > package P.C1 is > private > > I1 : Integer; > > end P.C1; > > with P.C1; > package P.C2 is > > I2 : Integer; > > private > > I3 : Integer := P.C1.I1; > > end P.C2; -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-21 0:00 ` Tucker Taft @ 1999-06-22 0:00 ` Richard D Riehle 1999-06-22 0:00 ` Dale Stanbrough 0 siblings, 1 reply; 22+ messages in thread From: Richard D Riehle @ 1999-06-22 0:00 UTC (permalink / raw) In article <376E9EEB.322A3F39@averstar.com>, Tucker Taft <stt@averstar.com> wrote: >Oops, right you are. The "idiom" I was misremembering was actually to >create an extra level in the hierarchy, with all of the public >children made into public children of this intermediate level, >with the intermediate level spec having only a private part. >You could then use library unit renaming to hide the presence >of this intermediate level, if you wanted to. I believe Robert >Eachus suggested this approach originally. > >E.g.: > package P.Hidden_Level is > private > ... -- private stuff > end; > > package P.Hidden_Level.C1 is > ... > private > ... -- can see private decls of P.Hidden_Level > end; > > with P.Hidden_Level.C1; > package P.C1 renames P.Hidden_Level.C1; > >-Tuck Thanks Tucker. This is a good idea. Also, consider, package P.Hidden_Level.Public_Level is type some-type is tagged private; -- some publicly exported services private ... end P.Hidden_Level.Public_Level ; package body P.Hidden_Level.Public_Level is -- implement exported services using the -- private services in the hierarchy since -- the body can see the private declarations -- of parent its units. end P.Hidden_Level.Public_Level; Might be a good technique for creating a cascade of child packages where most of the hierarchy will consist of private specifications. The end of the hierarchy would be a public specification with a body implemented using those private specifications. This could prevent premature use of a well-formed set of decompositions while still modeling several levels of abstraction. I wonder if this is also useful with Tucker's earlier example of dispatching on privately declared operations. Seems there are some good possibilities for powerful design strategies in this idea. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-22 0:00 ` Richard D Riehle @ 1999-06-22 0:00 ` Dale Stanbrough 1999-06-22 0:00 ` Richard D Riehle 1999-06-22 0:00 ` Matthew Heaney 0 siblings, 2 replies; 22+ messages in thread From: Dale Stanbrough @ 1999-06-22 0:00 UTC (permalink / raw) Richard D Riehle wrote: " Thanks Tucker. This is a good idea. Also, consider, package P.Hidden_Level.Public_Level is type some-type is tagged private; -- some publicly exported services private ... end P.Hidden_Level.Public_Level ; package body P.Hidden_Level.Public_Level is -- implement exported services using the -- private services in the hierarchy since -- the body can see the private declarations -- of parent its units. end P.Hidden_Level.Public_Level;" It's still a bit ordinary though. The services offered in the public level can't rely on abstractions advertised in the private section, which I see as the major failure of this model. Dale ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-22 0:00 ` Dale Stanbrough @ 1999-06-22 0:00 ` Richard D Riehle 1999-06-22 0:00 ` Matthew Heaney 1 sibling, 0 replies; 22+ messages in thread From: Richard D Riehle @ 1999-06-22 0:00 UTC (permalink / raw) In article <dale-2206991424480001@192.168.0.2>, dale@cs.rmit.edu.au (Dale Stanbrough) wrote: >Richard D Riehle wrote: > > package P.Hidden_Level.Public_Level is > -- code deleted > package body P.Hidden_Level.Public_Level is -- code deleted > >It's still a bit ordinary though. The services offered in the >public level can't rely on abstractions advertised in the private >section, which I see as the major failure of this model. I see it differently -- not as a failure but as an opportunity for powerful design of abstractions. It might be the case that we want to make some specifications available for type derivation with a hierarchy of types, T'Class, as an implementation detail, but hide those implementation details from the final user of some public class. I wonder if this is one way for an Ada designer to differentiate implementation inheritance from interface inheritance. The type exported from the public package will be a pure interface, a contract with some client. The abstractions in the parent packages, those with no public specifications, can safely focus on implementation inheritance without the risk that the client will inadvertantly enter the hierarchy at the wrong place. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-22 0:00 ` Dale Stanbrough 1999-06-22 0:00 ` Richard D Riehle @ 1999-06-22 0:00 ` Matthew Heaney 1999-06-23 0:00 ` Dale Stanbrough 1 sibling, 1 reply; 22+ messages in thread From: Matthew Heaney @ 1999-06-22 0:00 UTC (permalink / raw) On 22 Jun 1999 14:24, dale@cs.rmit.edu.au (Dale Stanbrough) wrote: > package P.Hidden_Level.Public_Level is > type some-type is tagged private; > -- some publicly exported services > private > ... > end P.Hidden_Level.Public_Level ; > > package body P.Hidden_Level.Public_Level is > -- implement exported services using the > -- private services in the hierarchy since > -- the body can see the private declarations > -- of parent its units. > end P.Hidden_Level.Public_Level;" > > It's still a bit ordinary though. The services offered in the public > level can't rely on abstractions advertised in the private section, > which I see as the major failure of this model. Yes, but you can make use of them in the private region. For example, this would be a handy way to implement the full view (declared in the private region) of a private type (whose partial view is declared in the public region). As was suggested in earlier posts: 1) Declare the private stuff in the private region of the root package. This way you can get rid of the intermediate package: package P is private <private stuff here> end P; package P.C is <public stuff> private <private stuff that depends on private stuff in P> end P.C; 2) Declare the private stuff in a child, declare grandchildren that use that private stuff, and then rename the grandchildren as children: package P is end P; package P.Private_Stuff is private <private stuff> end; package P.Private_Stuff.C is <public stuff> private <private stuff that depends on private stuff in P.Private_Stuff> end; package P.C renames P.Private_Stuff.C; The idea behind both of these schemes is to hide that fact that private stuff is being used at all. You don't what to expose publicly (in the form of an intermediate package in the hierarchy) what is essentially an implementation issue. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-22 0:00 ` Matthew Heaney @ 1999-06-23 0:00 ` Dale Stanbrough 1999-06-23 0:00 ` Matthew Heaney 0 siblings, 1 reply; 22+ messages in thread From: Dale Stanbrough @ 1999-06-23 0:00 UTC (permalink / raw) Matthew Heaney wrote: " Yes, but you can make use of them in the private region. For example, this would be a handy way to implement the full view (declared in the private region) of a private type (whose partial view is declared in the public region). As was suggested in earlier posts: 1) Declare the private stuff in the private region of the root package. This way you can get rid of the intermediate package: [example deleted]" I don't particuarly like this scheme, because it relies on all the children having access to the private details of the type. "2) Declare the private stuff in a child, declare grandchildren that use that private stuff, and then rename the grandchildren as children: [example deleted] The idea behind both of these schemes is to hide that fact that private stuff is being used at all. You don't what to expose publicly (in the form of an intermediate package in the hierarchy) what is essentially an implementation issue." Still not quite what i want to do. I would like to be able to build subsystems where I have internal private packages whose type and operations are visible within the private hierachy, but can also be used to build (in the private parts of public packages) abstractions that can be seen by everyone. (Having reread my original post i realise now that i didn't mention private packages, which may have caused some confusion). E.g. ---------------------------------------------------- package P is end P; ---------------------------------------------------- private package P.Private_Stuff is type PPS is private; blah blah blah; private <stuff> end; ---------------------------------------------------- with P.Private_Stuff; use P.Private_Stuff; package P.Public_Stuff is type PPublic is private; blah blah blah; private type PPublic is -- a record with PPS components, -- or "new PPS;" end; ---------------------------------------------------- Of course there would have to be a restriction that the public section of P.Public_Stuff could not export any of the information from the private package (e.g. no renames, subtypes etc). Your 2nd proposal has the problem that implementation of types declared in P.Private_Stuff can be seen by any child packages, so you loose any ability to do hiding of abstractions -within- a hierachy. Dale ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-23 0:00 ` Dale Stanbrough @ 1999-06-23 0:00 ` Matthew Heaney 1999-06-23 0:00 ` Dale Stanbrough 0 siblings, 1 reply; 22+ messages in thread From: Matthew Heaney @ 1999-06-23 0:00 UTC (permalink / raw) On 23 Jun 1999 11:54, dale@cs.rmit.edu.au (Dale Stanbrough) wrote: > Your 2nd proposal has the problem that implementation of types > declared in P.Private_Stuff can be seen by any child packages, so you > loose any ability to do hiding of abstractions -within- a hierachy. But that's already the case: package P is type T is tagged private; ... private type T is ...; end P; package P.C1 is ... package P.C2 is ... Every child (C1, C2) has access to the private part of its parent (P). There's no such thing as "hiding within a hierarchy." Child packages were designed not to hide visibility from within the hierarchy. They were designed to /deliberately/ expose the private part to children, and to allow you to easily identify which packages have that private knowledge. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-23 0:00 ` Matthew Heaney @ 1999-06-23 0:00 ` Dale Stanbrough 1999-06-23 0:00 ` Richard D Riehle 0 siblings, 1 reply; 22+ messages in thread From: Dale Stanbrough @ 1999-06-23 0:00 UTC (permalink / raw) Matthew Heaney wrote: " Every child (C1, C2) has access to the private part of its parent (P). There's no such thing as "hiding within a hierarchy."" There is. Consider the following... pacakge P is end P; package P.A is type X is private; ... end A; with P.A; package P.B is type Y is private; -- operations on Y private type Y is record Item : X; end record; end P.B; Clearly package P.B has no access to the private implementations of package P.A (and they -are- in the same hierachy, it's just that one is not a lineal (package) descendent of the other). Consider the following... The example above compiles fine. External users of type Y are happy. Package P.B is prevented from knowing the internal implementation of type X. But let's also assume that we didn't want to give access to type X to the rest of the world. What I would -like- to do is to make P.A private, so that it can't be seen, but still retain type X's private status. It would be nice if i could simply make P.A. a private package. Unfortunately Ada confuses "compilation privacy" with "implementation privacy". I am forced (simply because I want to hide some internal details) to sacrifice my privacy designs to the gods of compilation efficiency (which is the opposite of what "private" means in the rest of Ada). " Child packages were designed not to hide visibility from within the hierarchy. They were designed to /deliberately/ expose the private part to children, and to allow you to easily identify which packages have that private knowledge." Yes I know that, but I'm not concerned about parent/child packages, but about sibling (or rather non lineal descendant) packages/privacy issues. I think that the current situation forces too much exposure of implementation issues that will cause package hierachies to end up a large entagled mess, because we are continually forced to abandon internal privacy goals to meet external ones. Dale ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-23 0:00 ` Dale Stanbrough @ 1999-06-23 0:00 ` Richard D Riehle 1999-06-23 0:00 ` Vladimir Olensky ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Richard D Riehle @ 1999-06-23 0:00 UTC (permalink / raw) In article <dale-2306991359560001@dale.cs.rmit.edu.au>, dale@cs.rmit.edu.au (Dale Stanbrough) wrote: >Yes I know that, but I'm not concerned about parent/child packages, but >about sibling (or rather non lineal descendant) packages/privacy issues. > >I think that the current situation forces too much exposure of >implementation issues that will cause package hierachies to end up >a large entagled mess, because we are continually forced to abandon >internal privacy goals to meet external ones. The Ada private part is analogous to the C++ protected part. A derivation of a C++ class may see the protected part of its parent. Ada has ways to strengthen the encapsulation if you wish. Private packages are one way. Another useful technique is opaque types. An opaque type is a type that contains nothing but a reference to data. This is quite easy using Ada's incomplete type definition. These can be tagged for extensibility while hiding all the details within a package body. Consider, package P is type T is tagged private; -- operations on T private type Item; type Item_Pointer is access all Item; type T is tagged record Data : Item_Pointer; -- a reference to hidden data end record; end P; Now T can still be extended, but the implementation of Item is deferred to the package body. If you want to be really clever, you can create a private child package of P where Item is fully defined in the private specification and with'ed into the body of P. This enforces the rule that nothing but a package body rooted at P can access the public specification of the private child. This preserves extensibility within the hierarchy but prevents access by any ordinary client. This example follows the Modula-2 convention for information hiding using opaque types. Note that Modula-3 improves upon this through reference types that are followed with a reserved word, REVEAL,in the IMPLEMENTATION MODULE. In the final analysis, though, encapsulation is something like the lock on a safe that is intended to keep honest people honest. If someone is determined to break encapsulation, they will find a way to do it, even if they have to crack open your package body and perform "open heart surgery." Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-23 0:00 ` Richard D Riehle @ 1999-06-23 0:00 ` Vladimir Olensky 1999-06-23 0:00 ` Richard D Riehle 1999-06-23 0:00 ` John Duncan 1999-06-24 0:00 ` Dale Stanbrough 2 siblings, 1 reply; 22+ messages in thread From: Vladimir Olensky @ 1999-06-23 0:00 UTC (permalink / raw) Richard D Riehle wrote in message <7kr4pc$bb9@dfw-ixnews15.ix.netcom.com>... >In article <dale-2306991359560001@dale.cs.rmit.edu.au>, > dale@cs.rmit.edu.au (Dale Stanbrough) wrote: > >This example follows the Modula-2 convention for information >hiding using opaque types. Note that Modula-3 improves upon this >through reference types that are followed with a reserved word, >REVEAL,in the IMPLEMENTATION MODULE. There is very interesting article about using M3 opaque types. It was published in Dr.Dobb's journal in October 1995 and now it is available online at http://www.research.digital.com/SRC/modula-3/html/partial-rev/index.html It includes C++, Ada 95 and M3 examples. I think everyone find this article very interesting. Ada private child packages come very close to M3 opaque types. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-23 0:00 ` Vladimir Olensky @ 1999-06-23 0:00 ` Richard D Riehle 1999-06-24 0:00 ` Hyman Rosen 0 siblings, 1 reply; 22+ messages in thread From: Richard D Riehle @ 1999-06-23 0:00 UTC (permalink / raw) In response to my example of opaque types in Ada, In article <7kra6p$t5h$1@remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: >There is very interesting article about using M3 opaque types. It was >published in Dr.Dobb's journal >in October 1995 and now it is available online at >http://www.research.digital.com/SRC/modula-3/html/partial-rev/index.html The article you cited by Steve Freeman is certainly a thoughtful and fair treatment of some of the issues related to interface inheritance versus implementation inheritance. It is especially potent in highlighting some of the drawbacks of C++, but I doubt any C++ users from the Dr. Dobbs readership paid serious attention to that. In Mr. Freeman's Ada example, he assumes that the private part of the package must contain a complete view of the data. That is exactly the opposite of the example I posted earlier. In Ada, we can declare an incomplete type, an access to that type, enclose within a tagged record a value of the access type, and defer the full description of the data until later. This is the essence of an opaque type. Opaque types are convenient in both Ada and Modula-3 because of their clear separation of interface module (package specification) from implementation module (package body). This is more difficult in Java, C++, and even Eiffel, as demonstrated in Mr. Freeman's article. Although the Ada opaque type must be implemented using an access type, it does overcome one of the complaints Mr. Freeman has about Ada's structure: changes can be made to the full data definition, the implementation, in the package body without changing the interface. I agree that the use of an Ada access type to design an opaque type is not quite as elegant as the semantics of the Modula-3 REVEAL keyword. However, it is effective, clean, efficient and expressive enough to permit a an opaque type design that distinguishes implementation inheritance from specification inheritance. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-23 0:00 ` Richard D Riehle @ 1999-06-24 0:00 ` Hyman Rosen 1999-06-24 0:00 ` Richard D Riehle 0 siblings, 1 reply; 22+ messages in thread From: Hyman Rosen @ 1999-06-24 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > In Mr. Freeman's Ada example, he assumes that the private part of > the package must contain a complete view of the data. That is exactly > the opposite of the example I posted earlier. which was -- package P is type T is tagged private; -- operations on T private type Item; type Item_Pointer is access all Item; type T is tagged record Data : Item_Pointer; -- a reference to hidden data end record; end P; > In Ada, we can declare an incomplete type, an access to that type, > enclose within a tagged record a value of the access type, and defer > the full description of the data until later. This is the essence of > an opaque type. Opaque types are convenient in both Ada and Modula-3 > because of their clear separation of interface module (package > specification) from implementation module (package body). This is > more difficult in Java, C++, and even Eiffel, as demonstrated in > Mr. Freeman's article. In C++ we can do the following. I'm not sure if I've duplicated the semantics you're aiming for, but I think I did. Unless I'm not understanding your intent, I don't see why my C++ is any more difficult than your Ada. class P { private: class Item; typedef Item *Item_Pointer; public: class T { public: // operations on T private: Item_Pointer Data; }; }; ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-24 0:00 ` Hyman Rosen @ 1999-06-24 0:00 ` Richard D Riehle 0 siblings, 0 replies; 22+ messages in thread From: Richard D Riehle @ 1999-06-24 0:00 UTC (permalink / raw) In article <t7emj1y32b.fsf@calumny.jyacc.com>, Hyman Rosen <hymie@prolifics.com> wrote: >In C++ we can do the following. I'm not sure if I've duplicated the >semantics you're aiming for, but I think I did. Unless I'm not >understanding your intent, I don't see why my C++ is any more >difficult than your Ada. > >class P >{ >private: > class Item; > typedef Item *Item_Pointer; >public: > class T > { > public: > // operations on T > private: > Item_Pointer Data; > }; >}; I would first refer you to Mr. Freeman's article since he has more eloquently examined this issue than I. A key difference between C++ and Ada is that Ada _requires_ a separation of specification from implementation. This is also true, for the most part, of the Modula series. Although the semantics of an opaque type can be expressed in C++, I believe the best and most direct expression of this mechanism is found in Modula-3, then Ada, and lastly other languages, such as C++. The argument about whether a particular construct _can_ be expressed in this or that language is often far from the issue of direct expressibility. There are certain things that are more expressible in C++ than Fortran, others more expressible in Fortran than C++, and still others better expressed in COBOL than in C++ or Java. There are ideas we can express in a single word in Japanese or Chinese that might take a paragraph in English. This does not make Japanese better than English. It is simply a matter of ease of expressibility. Also, the issue of expressive power is quite subjective and almost always derives from one's personal preferences and experiences, seldom from faultless logic. I am sure there are Ada enthusiasts who will disagree with my contention that Modula-3 is better at expressing opaque types than Ada. Overall, my language preference still remains Ada, even though C++, Java, Modula-3 and Object COBOL all have features of expressiveness for certain constructs that are better than a similar construct in Ada. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-23 0:00 ` Richard D Riehle 1999-06-23 0:00 ` Vladimir Olensky @ 1999-06-23 0:00 ` John Duncan 1999-06-24 0:00 ` Dale Stanbrough 2 siblings, 0 replies; 22+ messages in thread From: John Duncan @ 1999-06-23 0:00 UTC (permalink / raw) >This example follows the Modula-2 convention for information >hiding using opaque types. Note that Modula-3 improves upon this >through reference types that are followed with a reserved word, >REVEAL,in the IMPLEMENTATION MODULE. Just a note: M3 allows the revelation of opaque subtypes at the interface level as well. That way you can publish a number of increasingly-challenging interfaces to a type, some of them unsafe, provided that the base implementation exports all of the interfaces. This way, you can have something like INTERFACE Thingy; TYPE T <: Public; TYPE Public = OBJECT METHODS safeMethods END; ... END Thingy; UNSAFE INTERFACE ThingyUnsafe; IMPORT Thingy; REVEAL Thingy.T <: Unsafe; TYPE Unsafe = Thingy.T OBJECT attributes METHODS unsafeMethods END; ... END ThingyUnsafe; UNSAFE MODULE Thingy EXPORTS ThingyUnsafe; IMPORT ThingyUnsafe; REVEAL T = ThingyUnsafe.Unsafe OBJECT moreAttributes METHODS moreMethods OVERRIDES ifaceMethod := MyMethodProcedure; END; ... END Thingy; The little "<:" operator tells the compiler about the subtyping relation. Each of the times T is declared as a subtype, it becomes more concrete, but not concrete enough to compile. When it comes down to the module level, someone has to define the type concretely. In order to do this, the methods are usually null until someone comes along and overrides the previous methods. It all works out very, very nicely. A lot of people on the m3 ng wonder whether the Ada committee reviewed opaque subtypes at all. It is a very neat feature for deep-down systems programming. There is no particular reason why unsafe things have to be published outside a library, but they are usually very useful within the library. That's where the opaque subtyping and partial revelations come in. (for more info on modula-3, go to http://www.m3.org/ ) -John ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-23 0:00 ` Richard D Riehle 1999-06-23 0:00 ` Vladimir Olensky 1999-06-23 0:00 ` John Duncan @ 1999-06-24 0:00 ` Dale Stanbrough 2 siblings, 0 replies; 22+ messages in thread From: Dale Stanbrough @ 1999-06-24 0:00 UTC (permalink / raw) Richard D Riehle wrote: An opaque type is a type that contains nothing but a reference to data. This is quite easy using Ada's incomplete type definition. These can be tagged for extensibility while hiding all the details within a package body. Consider..." Yes, but that forces me to change the representation that I may have chosen for very good reasons, just to get around what I view is a problem in how "private" works for packages. " In the final analysis, though, encapsulation is something like the lock on a safe that is intended to keep honest people honest. If someone is determined to break encapsulation, they will find a way to do it, even if they have to crack open your package body and perform "open heart surgery."" Yes, but this doesn't really address the issue at hand. What I am arguing is that Ada could have been -more- helpful than it is in supporting encapsulation, not that we need not worry about it encapsulation because people can break it if they want to (after all anyone can use unchecked-perversion to open up any private type they like!). Certainly encapsulation doesn't (or rather in Ada's case, shouldn't) end at the level of package hierachies. Dale ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Private Children 1999-06-21 0:00 ` Ted Dennison 1999-06-21 0:00 ` Tucker Taft @ 1999-06-25 0:00 ` Robert Dewar 1 sibling, 0 replies; 22+ messages in thread From: Robert Dewar @ 1999-06-25 0:00 UTC (permalink / raw) In article <7klja3$c0p$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > In article <m3bteacxb8.fsf@mheaney.ni.net>, > Matthew Heaney <matthew_heaney@acm.org> wrote: > > Can a public child package with its private sibling? > > > > Almost exactly one month ago, I posted the exact same > question. Go to deja.com and search for a thread titled > "Children of private nhcompilation units" to see the > discussion. If you go there you will find out that it is a totally unrelated issue, not at all "the exact same question". Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~1999-06-25 0:00 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-06-20 0:00 Private Children Matthew Heaney 1999-06-21 0:00 ` Dale Stanbrough 1999-06-21 0:00 ` Ted Dennison 1999-06-21 0:00 ` Tucker Taft 1999-06-21 0:00 ` Matthew Heaney 1999-06-21 0:00 ` Matthew Heaney 1999-06-21 0:00 ` Tucker Taft 1999-06-22 0:00 ` Richard D Riehle 1999-06-22 0:00 ` Dale Stanbrough 1999-06-22 0:00 ` Richard D Riehle 1999-06-22 0:00 ` Matthew Heaney 1999-06-23 0:00 ` Dale Stanbrough 1999-06-23 0:00 ` Matthew Heaney 1999-06-23 0:00 ` Dale Stanbrough 1999-06-23 0:00 ` Richard D Riehle 1999-06-23 0:00 ` Vladimir Olensky 1999-06-23 0:00 ` Richard D Riehle 1999-06-24 0:00 ` Hyman Rosen 1999-06-24 0:00 ` Richard D Riehle 1999-06-23 0:00 ` John Duncan 1999-06-24 0:00 ` Dale Stanbrough 1999-06-25 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox