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.3 required=5.0 tests=BAYES_00,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: Matthew Heaney Subject: Re: Can't export object of private type Date: 1999/03/08 Message-ID: #1/1 X-Deja-AN: 452500593 Sender: matt@mheaney.ni.net References: <7bk6gh$6d9$2@plug.news.pipex.net> NNTP-Posting-Date: Mon, 08 Mar 1999 01:02:02 PDT Newsgroups: comp.lang.ada Date: 1999-03-08T00:00:00+00:00 List-Id: "Nick Roberts" writes: > Also, you need to remove the function Solo_T from package T (it does nothing > and won't compile), and move the declaration of Self from the private part > of package T.Child (where it doesn't need to be, and will cause an > unnecessary dependency) to the package's body. I would probably declare the singleton in the package body too, not in the private region of the spec. > The 'access' parameters in the subprograms need only be 'in out' > parameters; this is (pointedly!) a case where access parameters serve > no useful purpose (because the objects are always going to be declared > at library level). No. There is a legitimate reason for making the operations take access parameters. The reason is that, because this is a singleton abstraction, you must refer the (one) instance indirectly, via a pointer. But you don't want to have to always deference a pointer every time you use the object, and access parameters save you the trouble. The solution you're advocating would require that clients always dereference the pointer before invoking the operation: function Maze return Maze_Access; ... Get_Room (2, Of_Maze => Maze.all); But if the primitive operation takes an access parameter, then no explicit deference is necessary: ... Get_Room (2, Of_Maze => Maze); Access parameters allow you to manipulate singleton instances of a type using the same syntax as for non-singleton instances, which is exactly what we want. See my recent post in the ACM patterns archive, "Abstract Factory Revisited," for a discussion of these issues. As a matter of fact, I submitted that example specifically to address the issues that came up during this thread here on CLA.