Re: Can't export object of private type

[Matthew Heaney <matthew_heaney@acm.org>]

nospam@thanks.com.au (Don Harrison) writes:

> Sure. What I'm trying to acheive is a set of implementation techniques for 
> OO design that:
> 
>   a) Are consistent at least from the perspective of client code. 
>      For example, everything that is an object (including singletons) 
>      *looks like* an object (and not a module).
>   b) Map as directly as possible from the design.
>   c) Are idiomatic Ada.

The state machine package is "idiomatic Ada."  Your a) and c) goals may
be in conflict.

As I have argued in previous posts, don't export a singleton instance of
a type unless you have a compelling need to.  Types should really only
be used to implement an abstraction that has an unbounded number of
instances.

If you know up front how many "instances" of an abstraction you have
--what I call the "well-known objects" pattern-- then a state machine
package is probably the way to go.  

For example, in the embedded systems I build, you just refer to the
abstraction as "digitizer 1" or "depth detector 2" or "target 11", as in

package Digitizers is

  type Digitizer_Id is range 1 .. 2;

  type Digitizer_Mode is (...);

  procedure Set_Mode (Digitizer : Digitizer_Id;
                      Mode      : Digitizer_Mode);

  procedure Acquire (Digitizer : Digitizer_Id);

  procedure Cancel_Acquisition (Digitizer : Digitizer_Id);

...
end Digitizers;


An abstract data type wouldn't buy you very much except syntactic
overhead.

Thinking in terms of packages (or "modules", if you prefer that term) is
fundamental to Ada programming.  If you're using singleton instances of
types everywhere, motivated perhaps by some notion of "purity," then
that may be a sign that you're fighting the language.

In a typical Ada application, some abstractions are implemented as state
machine packages, and some abstractions are implemented as instances of
an abstract data type.  There is nothing odd or unnatural about this.