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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,772ae8afc5db35f2 X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: Can't export object of private type Date: 1999/03/09 Message-ID: <7c3oeu$jr1$2@plug.news.pipex.net>#1/1 X-Deja-AN: 453057954 References: <7bmgfb$2d3$1@plug.news.pipex.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Newsgroups: comp.lang.ada Date: 1999-03-09T00:00:00+00:00 List-Id: Matthew Heaney wrote in message ... [...] |> Just wondering.. Would private child packages have been a better |> alternative to nested packages? [I have a pathological aversion to nested |> packages.] | |If you have a choice between a child and a nested package, then use a |child. The reason, of course, is to push module dependencies into the |child. By moving the dependency to a child, you only have to recompile |the subtree, if that module changes. In fact, in the planetary example I gave, the inner nested package was unnecessary (I simply fell foul of a GNAT 3.11p bug, which causes the need for a declaration of an overriding abstract subprogram before the body of the subprogram*). It may be advantageous to use child packages, under some (unlikely) circumstances. [...] |This is basically why always say, Don't implement a singleton as a type, |unless you have a compelling need to. It just creates module |dependencies that wouldn't be there otherwise. I would personally agree with this injunction, in general. In Ada, it produces a simpler result, except for the polymorphism, which can be simulated as required by a big 'case' statement (as I demonstrated in an earlier example). Of course, this is slightly kludgeous, and may, in some (perhaps many) cases, be so onerous as to make the type-based solution preferable. There is, however, another kind of situation that the package-based approach does not solve. This is where a base type (with its promised operations) already exists, and cannot be (or is not to be) revoked (e.g. because it is already used elsewhere, or because there will be some non-singleton types derived from it). The best solution to this situation is (unfortunately) the introduction of the 'single record extension' object declaration to the language (which I would hope could be done at the next revision, barring a better alternative or a crushing objection). ------------------------------------- Nick Roberts ------------------------------------- * this bug will be fixed in version 3.12