Re: Can't export object of private type

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

Nick Roberts wrote:

:Don Harrison wrote ...
:|Nick Roberts wrote:
:|
:|:Also, you need to remove the function Solo_T from package T (it does
:nothing
:|
:|It exports a reference to the singleton.
:
:It's definitiely unnecessary, and doesn't export anything (that needs to be
:exported).  It is unnecessary.

Yes, you're right. As the code stands, it isn't necessary. What I really 
want is an abstract primitive operation, not so much for polymorphism, but 
so that derivations are forced to supply an access function to their (private) 
variable "Self". This is a form of contract which derivations must meet.


:|: .. and won't compile),
:|
:|GNAT didn't have any trouble.
:
:I have to agree with this -- I've tried it myself.  I'm still trying to work
:out why.  The whole thing also works perfectly well if you delete this
:function declaration too (try it!).

You're right.


:|: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.
:|
:|An unnecessary dependency on what?
:
:
:The idea is to move everything not to do with the 'public' face of your
:singletons out of package specs and into the bodies.  This way, if you nned
:to change anything about the implementation of these objects, it will only
:cause recompilation of the package bodies: if you have to change anything in
:the specs, this will (potentially) cause (the necessity of) recompilation of
:the specs, the bodies AND all the clients which use the specs.  You
:generally want to avoid this.

Got you. There are two opposing needs here:

  b) On one hand, you want to decrease compilation dependencies, 
     as you suggest.

  a) On the other, it's convenient for all private declarations 
     to be in the one place (rather than being split between private 
     part of spec and body). This makes the mechanics of reading 
     code less arduous - declarations in the private part of the spec 
     and operations using them can be viewed separately in 2 windows. 
     However, if declarations are also placed in the body, the body 
     window must be scrolled constantly to view declarations.
     To eliminate scrolling, you would need 3 windows! - spec, body 
     declarations and body operations.


:|:The 'access' parameters in
:|:the subprograms need only be 'in out' parameters; this is (pointedly!) a
:|:case where access parameters serve no useful purpose..

Matt has addressed this issue, so I won't cover it, except for..

:|  - That entity can't be corrupted because access-parameters are
:|    in-mode.
:
:Wrong.  The access value itself can't be changed, but the entity it
:references can.

You misunderstand. By "entity", I meant the reference.


:|: [this is .. a case where access parameters serve no useful purpose] 
:|:(because the objects are always going to be declared at library level).

Matt seems to have covered this (so I won't).

: .. However, I have provided a template example below which
:is :-)  I hope ;-)  This shows no less than two levels of derivation, and
:may seem a little 'overkill'.  

[your example]

Just wondering.. Would private child packages have been a better 
alternative to nested packages? [I have a pathological aversion to nested 
packages.]


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