* Children of private compilation units @ 1999-05-18 0:00 dennison 1999-05-19 0:00 ` Tucker Taft 0 siblings, 1 reply; 4+ messages in thread From: dennison @ 1999-05-18 0:00 UTC (permalink / raw) I have a situation where Gnat and ObjectAda are giving me conflicting results. The situation is basicly this package A is .... private package A.B is ... package A.B.C is ... with A.B.C; procedure A.Fred is ... This compiled fine for one developer using ObjectAda. But with Gnat, I get: current unit must also be private descendant of "JPATS_Aircraft_Body" on the with statement. So what are compilers *supposed* to do in this situation? I can't find anything helpful in the LRM. Cohen seems to say this is OK. What's the truth? -- 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] 4+ messages in thread
* Re: Children of private compilation units 1999-05-18 0:00 Children of private compilation units dennison @ 1999-05-19 0:00 ` Tucker Taft 1999-05-25 0:00 ` Robert Dewar 0 siblings, 1 reply; 4+ messages in thread From: Tucker Taft @ 1999-05-19 0:00 UTC (permalink / raw) dennison@telepath.com wrote: > > I have a situation where Gnat and ObjectAda are giving me conflicting > results. I believe ObjectAda is in the right (see below). > The situation is basicly this > > package A is .... > > private package A.B is ... > > package A.B.C is ... > > with A.B.C; > > procedure A.Fred is ... > > This compiled fine for one developer using ObjectAda. But with Gnat, I > get: > current unit must also be private descendant of "JPATS_Aircraft_Body" > on the with statement. I presume you meant to say: "current unit must also be private descendant of package A". > So what are compilers *supposed* to do in this situation? I can't find > anything helpful in the LRM. Cohen seems to say this is OK. What's the > truth? The relevant RM paragraph is RM95 10.1.2(8): If a with_clause of a given compilation_unit mentions a private child of some library unit, then the given compilation unit shall be either the declaration of a private descendant of that library unit or the body or subunit of a (public or private) descendant of that library unit. The only possible source of confusion here is whether "procedure A.Fred is" is a declaration or a body. You might try creating a separate explicit procedure "spec" for A.Fred and see whether GNAT likes it any better. However, as you can see from the above RM wording, that shouldn't be necessary, because even if there is no separate spec for A.Fred, it is still a body (even if also a declaration), and so the second half of the rule applies, meaning the with_clause is legal. I suppose another possible source of confusion is whether A.B.C is a private child. The answer is no, since the word "private" doesn't appear on the declaration of C. C is a public child of a private child of A. There are no restrictions on mentioning public children per-se, even if one of their ancestors is private. The error, if any, would be on mentioning the private ancestor, and in this case, the private ancestor is legal to mention, because A.Fred is the body of a descendant of A. > > -- > 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] 4+ messages in thread
* Re: Children of private compilation units 1999-05-19 0:00 ` Tucker Taft @ 1999-05-25 0:00 ` Robert Dewar 1999-05-25 0:00 ` dennison 0 siblings, 1 reply; 4+ messages in thread From: Robert Dewar @ 1999-05-25 0:00 UTC (permalink / raw) In article <37430B99.698B22FB@averstar.com>, Tucker Taft <stt@averstar.com> wrote: > dennison@telepath.com wrote: > > > > I have a situation where Gnat and ObjectAda are giving me conflicting > > results. > > I believe ObjectAda is in the right (see below). Actually it seems that GNAT is right, and Tuck has agreed with this position in a subsequent ARG discussion. This program is indeed illegal as it stands. I will let Tuck elucidate :-) Robert Dewar Ada Core Technologies --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.--- ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Children of private compilation units 1999-05-25 0:00 ` Robert Dewar @ 1999-05-25 0:00 ` dennison 0 siblings, 0 replies; 4+ messages in thread From: dennison @ 1999-05-25 0:00 UTC (permalink / raw) In article <7if7sg$j6n$1@nnrp1.deja.com>, Robert Dewar <dewar@gnat.com> wrote: > In article <37430B99.698B22FB@averstar.com>, > Tucker Taft <stt@averstar.com> wrote: > > dennison@telepath.com wrote: > > > > > > I have a situation where Gnat and ObjectAda are giving me > conflicting > > > results. > > > > I believe ObjectAda is in the right (see below). > > Actually it seems that GNAT is right, and Tuck has agreed with > this position in a subsequent ARG discussion. This program is > indeed illegal as it stands. I will let Tuck elucidate :-) Well, please do so. If the code is indeed illegal, I have a leg to stand on when I go to the developer and tell him to change it. Telling him to change it just to make gnat like it and make my life easier is a much harder sell. What parituclarly is illegal? Do all children of private packages now have to be private? Or is it just illegal to "with" a public child of a private package outside of the source tree rooted at the private parent? I'll submit a bug report to the appropriate vendor, if I can get a consensus on who that is. :-) -- 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] 4+ messages in thread
end of thread, other threads:[~1999-05-25 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-05-18 0:00 Children of private compilation units dennison 1999-05-19 0:00 ` Tucker Taft 1999-05-25 0:00 ` Robert Dewar 1999-05-25 0:00 ` dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox