Re: Can't export object of private type

[Matthew Heaney <matthew_heaney@acm.org>]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> 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.

<http://www.acm.org/archives/patterns.html>

As a matter of fact, I submitted that example specifically to address
the issues that came up during this thread here on CLA.