Re: Can't export object of private type

[nospam@thanks.com.au (Don Harrison)]

Matt Heaney wrote:

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

:>   function Solo_T return Access_Class_T_Type is abstract;
:
:I don't understand why you declared function Solo_T as abstract.  It is
:not a primitive type for T_Type.
:
:Even if it weren't abstract, why do you need it there in the root
:package?  All the (singleton) instances live in child packages.

See my response to Nick.


:>   type Access_Class_T_Child_Type is access all T_Child_Type'Class;
:> 
:>   function Solo_T return Access_Class_T_Child_Type;
:
:Why does Solo_T return a pointer to a class-wide type?  You want to have
:a function that returns a pointer to the _specific_ type, because you're
:pointing to an object of that type.

You're probably right.


:There's no need for dispatching, so return the specific type:
:
:  type T_Child_Access is access all T_Child_Type;
:
:  function Solo_T return T_Child_Access;

Perhaps not. But, there *is* a need to force derivations to provide an 
access function ..which apparently Ada can't give us.


:>   type T_Index_Type is new Integer range 1 .. 2;
:>   type T_Array_Type is array (T_Index_Type) of Access_Class_T_Type;
:> 
:>   T_Array: T_Array_Type := (
:>     1 => T.Child.Solo_T.all'Access,          -- 1)
:>     2 => T.OTher_Child.Solo_T.all'Access);   -- 1)

:> 1) Can this ugly stuff be avoided?
:
:Yes.
:
:What you did here was to declare some data (an array of pointers to
:singletons) outside of any object, and perform an operation on that data
:(display each object).
:
:This isn't in the spirit of the object-oriented paradigm, in which data
:is encapsulated by an object, and you send the object a message to
:operate in that data.  Your implementation is just the opposite, and the
:symptom is "ugly stuff."

Small nit.. The OO paradigm says nothing about sending messages. Although 
many people use this terminology (from dynamically-typed OOPLs), it's 
better to speak of dispatching calls in the context of statically-typed 
OOPLs.

The use of the main program as a client has more to do with a desire to 
simplify the example while satisfying Ada's requirement for a main program 
than indicating a design preference on my part. 

The "ugly stuff" is not the result of lax design.

It's caused by the fact that Ada requires explicit syntax to represent 
the notions of class membership ("'Class") and referencing ("access").
In many OOPLs, these details are implicit rather than explicit, thus 
relieving the developer from having to represent them explicitly. 
Ada has always had a literal approach to typing syntax and semantics and 
this philosophy has been preserved in its OO typing. Hence, explicit syntax 
is used to distinguish between:

  - Objects and references to them.
  - Specific and classwide types.

You can hide that syntax from clients, as you suggest, but that isn't 
the same as removing it.


:A better way to think of this problem is that you have a (singleton)
:collection object containing (pointers to) all the singleton instances
:in your type hierarchy. ..

Agree.


:Now, here's where we get back to our state-machine paradigm: the
:subsystem rooted at package T _is_ the collection object.

This would be the wrong way to model it, IMO. An object and a collection 
of them should be separate abstractions.


:  pragma Elaborate_Body;

This is a welcome addition to Ada. It gives what the default semantics 
should have been from the beginning. 


:Each time Register is called, it increments the Last index, and inserts
:the item into the array.  (You don't have to worry about synchronization
:issues, because elaboration is linear.)

Right.


-- 
Don (Harrison).   donh at syd.csa.com.au