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.9 required=5.0 tests=BAYES_00,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7eaf9f2597de2259 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-10 02:48:45 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!195.64.68.27!newsgate.cistron.nl!bullseye.news.demon.net!news.demon.co.uk!demon!pipehawk.demon.co.uk!not-for-mail From: john.mccabe@emrad.com.nospam (John McCabe) Newsgroups: comp.lang.ada Subject: Re: on package naming, should the word "_pkg" be part of it? Date: Wed, 10 Oct 2001 09:47:04 GMT Organization: Emrad Ltd Message-ID: <3bc40fef.1827097@news.demon.co.uk> References: <9pif1o01btl@drn.newsguy.com> <3BBD12F1.9BED0B70@acm.org> <3BC0B1D4.21C79A8@acm.org> <3bc1d137.20930256@news.demon.co.uk> <3bc3ffb5.826258@news.demon.co.uk> NNTP-Posting-Host: pipehawk.demon.co.uk X-NNTP-Posting-Host: pipehawk.demon.co.uk:158.152.226.81 X-Trace: news.demon.co.uk 1002707237 nnrp-08:25642 NO-IDENT pipehawk.demon.co.uk:158.152.226.81 X-Complaints-To: abuse@demon.net X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:14129 Date: 2001-10-10T09:47:04+00:00 List-Id: On Wed, 10 Oct 2001 08:04:10 GMT, john.mccabe@emrad.com.nospam (John McCabe) wrote: Francisco I've just been reminded of where the problem lies with respect to the use of Object as a 'class' name (with thanks to Martin Ellerker). Consider the following Parent and Child classes (similar to what I mentioned in my earlier message): File: GParent.ads ----------------- generic package GParent is type Object is abstract tagged null record; end GParent; File: GParent-GChild.ads ------------------------ with GParent; generic package GParent.GChild is type Object is new GParent.Object with null record; end GParent.GChild; Separate library level instantiations are provided as follows: File: IParent.ads ----------------- with GParent; package IParent is new GParent; File: IChild.ads ---------------- with IParent; with GParent.GChild; package IChild is new IParent.GChild; So far so good. A test program as follows compiles and runs without error (unless I've typed something in wrongly) File: TestG.adb --------------- with IChild; procedure TestG is begin null; end TestG; Now, however, if you then have a third level of Generic class, say.. File: GParent-GChild-GGChild.ads -------------------------------- with GParent.GChild; generic package GParent.GChild.GGChild is type Object is new GParent.GChild.Object with null record; end GParent.GChild.GGChild; and instantiate it with: File: IGChild.ads ----------------- with IChild; with GParent.GChild.GGChild; package IGChild is new IChild.GGChild; and change the test program to: File: TestG.adb --------------- with IGChild; -- Change to IGChild from IChild. procedure TestG is begin null; end TestG; we get the error: igchild.ads:3:01: instantiation error at gparent-gchild-ggchild.ads:4 igchild.ads:3:01: "GChild" not declared in "IParent". The cause of this is the explicit reference in line 4 of GParent-GChild-GGChild.ads to GParent.GChild.Object. Since IChild is the instantiation of GChild, it is IChild that, at this point, declares the GGChild 'class' we're interested in, not GParent.GChild. We could attempt to use the child-to-parent visibility rules to allow use to change GParent.Object and GParent.GChild.Object into just Object and Object, but then the scoping rules cause problems with errors: gparent-gchild.ads:4:24: object "Object" cannot be used before end of its declaration gparent-gchild-ggchild.ads:4:24: object "Object" cannot be used before end of its declaration So there you go. I realise this may seem like a complex and unrealistic example, but consider (the implementation we were looking at) the use of lists... At the Parent level you have a generic that defines a container for a type. At the Child level you have a linked list of objects of the type. At the grandchild level you have a doubly-linked list of object of the type. At the great-grandchild you have an ordered list of objects of the type. Similarly for Container - Tree - AVL Tree. There are, of course different implementations possible which may avoid this problem but, ultimately, the easiest way is to *avoid* using "Object" as the name of a 'class'. Hope this helps. The examples were compiled with GNAT 3.13p on Windows 2000.