Re: Full view of a private partial view cannot be a subtype

[Jere <jhb.chat@gmail.com>]

On Tuesday, December 5, 2017 at 3:12:43 PM UTC-5, Randy Brukardt wrote:
> "Jere" wrote in message 
> > On Monday, December 4, 2017 at 3:49:54 PM UTC-5, Randy Brukardt wrote:
> >> "Jere" wrote in message
> >> ...
> >> >   package New_Type1 is
> >> >      subtype Instance is Base.Instance;
> >> >      procedure Operation(Object : in out Instance);
> >> >
> >> >   private
> >> >
> >> >      procedure Operation(Object : in out Instance) renames 
> >> > Base.Operation;
> >> >   end New_Type1;
> >> >
> >> > (NOTE:  is there a better way to do this?)
> >>
> >> No, no better way yet, but maybe (large maybe here) in Ada 2020. (I'm
> >> leaving out all details because none have been determined yet and perhaps
> >> never will be for Ada 2020.)
> >
> > Sounds intriguing!
> >
> >>
> >> > This is all well and good, but sometimes while I as an implementer
> >> > want this kind of relationship, I don't necessarily want to expose
> >> > that relationship outside the private section of a package.  Here I
> >> > run into a problem as I cannot (as far as I can tell) do:
> >> >
> >> >   package New_Type2 is
> >> >      type Instance is tagged limited private;
> >> >      procedure Operation(Object : in out Instance);
> >> >   private
> >> >      subtype Instance is Base.Instance;
> >>
> >> This is illegal; a private type has to be completed with a full type, not 
> >> a
> >> subtype. (If you have a compiler that is allowing this, it is 
> >> confused...)
> >
> > Yep, that was my comment.  Basically I have a low level package that is 
> > used
> > to create many higher level, more client friendly packages:
> >
> > generic
> >   type Input_Type(<>);
> >   with procedure Really_Dangerous_To_Call(Object : Input_Type);
> >   Value : Integer;
> > package Low_Level_Package
> >
> >   type My_Type is private;
> >   type Numeric_Type is <some implementation using Value>;
> >
> >   function Client_Friendly_Procedure
> >     (Object : My_Type)
> >      return Numeric_Type;
> >
> >   <other operations>
> >
> > private
> >   ...
> >
> > end Low_Level_Package;
> >
> > and I want to use it to make some more client friendly versions.
> > The procedure, Really_Dangerous_To_Call, isn't meant to be called
> > directly for a client.  It is meant to be used to setup implementations
> > behind the client packages.
> 
> If you control the entire design of the type hierarchy, the best way to do 
> this is to put "Really_Dangerous_to_Call" into the private part of the root 
> operation, and declare the child types in child packages. Then, the child 
> types can call the routine but clients cannot. (An added advantage is that 
> Really_Dangerous_to_Call can be dispatching in such a design.)
> 
> <SNIPPED Claw example>
>                                       Randy.
Thanks!

I think that still leaves me with the same issue.  All I really want out
of the client package is that it implements subtypes and renames of the
hidden package.  I don't really want to derive or extend or even do
composition if I have to because it leads to a lot of code that is easy
to mistype, difficult to parse through and read later on, and possibly add 
overhead (not normally an issue, but this is a low level core library
for me so I at least have to consider my implementation some).  All for
no readability benefit (and actual detriment to reading).

my assertion is that:

   subtype Thing is Core_Pkg.Thing;

   procedure Do_Something(The_Thing : in out Thing)
      renames Core_Pkg.Do_Something;
       

is easier to both maintain and read than:

   type Thing is new Core_Pkg.Thing with null record;
   
   procedure Do_Something(The_Thing : in out Thing);

   ...

   procedure Do_Something(The_Thing : in out Thing) is
   begin
      Core_Pkg.Thing(The_Thing).Do_Something;
   end Do_Something;

and:

   type Thing is record
      Parent_Thing : Core_Pkg.Thing;
   end record;

   procedure Do_Something(The_Thing : in out Thing);

   ...

   procedure Do_Something(The_Thing : in out Thing) is
   begin
      The_Thing.Parent_Thing.Do_Something;
   end Do_Something;

The first option completely conveys how I want to implement it while
the latter two options require additional code that adds no extra
readability and gives the reader/maintainer even more to parse through
(additional files and additional code) in order to determine what is
going on.  Furthermore it opens the maintainer up to more mistakes if
this needs to be done for a lot of functions (20+).  Additionally, the
complexity in both reading and maintainability only gets worse if the
operation signatures use multiple types that all need this same treatment.

I don't mind writing the extra stuff if it gives me more readability or
safety, but in this case it just feels like I am trading up readability
for more writing, which I don't like doing.  I like things easy to read.

You're correct in that using private packages hides the
Really_Dangerous_To_Call uses, but I'm still left with the original
issue that I am making my code more unreadable to do so.  I know that, 
based on this email chain, the latter two are my only options.  I was
just hoping there was a third option involving encapsulation of subtypes.

Out of the two later approaches, composition fairs much better in
readability (and possible overhead).  It just has much less readability
than the subtype method.

I can try to give better specifics if that helps.  I try to avoid that in
C.L.A though as it ends up sending people down paths that are tangential,
and my original question gets lost.  Also it helps to keep things simple
so that people can more easily help/answer.  I realize the onus is on me 
to be better at explaining what I need though.  So if you need better
specifics, I can do better to provide them.