Hiding a type

Hiding a type

[Ryan Tarpine]

Hello everyone!  I have just started learning Ada, and I am trying to 
use it on my next (personal) project.  That's generally how I learn 
things, by jumping in too deep (It worked to teach myself OCaml, so 
we'll see how this turns out! :)

What I'm wondering is how to hide a private type under a different, 
public name so variables can't be assigned.  I'm not sure how to say it 
best, so here's the simplest example of it:

package Test is
     type Hide is limited private;
private
     subtype Hide is Integer;
end Test;

I want to write functions that will return something of type Hide in a 
way so clients can't do anything except pass it to other functions.  I 
also don't want them to know if I change how I implement it.  (In my 
real program, I'm trying to hide that Foo returns an access type.) 
Please tell how I should actually do this

The exact errors I get are
test.ads:2:10: missing full declaration for private type "Hide"
test.ads:4:13: "Hide" conflicts with declaration at line 2

Thanks in advance,
Ryan

Re: Hiding a type

[Pat Rogers]

"Ryan Tarpine" <rtarpine@hotmail.com> wrote in message
news:3D27263F.7070101@hotmail.com...
> Hello everyone!  I have just started learning Ada, and I am trying to
> use it on my next (personal) project.  That's generally how I learn
> things, by jumping in too deep (It worked to teach myself OCaml, so
> we'll see how this turns out! :)

Do check out a textbook from the library -- it is worth the time -- or
take one of the on-line tutorials.  See www.adapower.com.

> What I'm wondering is how to hide a private type under a different,
> public name so variables can't be assigned.  I'm not sure how to say
it
> best, so here's the simplest example of it:

<snip>

> I want to write functions that will return something of type Hide in a
> way so clients can't do anything except pass it to other functions.  I
> also don't want them to know if I change how I implement it.  (In my
> real program, I'm trying to hide that Foo returns an access type.)
> Please tell how I should actually do this

package Opaque is
    type Hidden is limited private;
    -- declare the operations here that you want to export to clients
private
    type Hidden is access all Integer;
end Opaque;


--
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability
Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Hiding a type

[Ryan Tarpine]

Pat Rogers wrote:

> Do check out a textbook from the library -- it is worth the time -- or
> take one of the on-line tutorials.  See www.adapower.com.

I hope to get a textbook soon.  I'll have to buy one, as my local 
library is quite small.  I've read most of Ada Distilled and use it as a 
quick reference, and I don't find the reference manual too difficult to 
look through because I've used much more cumbersome languages before 
**ahem**c++**cough**.  The Lovelace tutorial is also wonderful.

>>I want to write functions that will return something of type Hide in a
>>way so clients can't do anything except pass it to other functions.  I
>>also don't want them to know if I change how I implement it.  (In my
>>real program, I'm trying to hide that Foo returns an access type.)
>>Please tell how I should actually do this
> 
> 
> package Opaque is
>     type Hidden is limited private;
>     -- declare the operations here that you want to export to clients
> private
>     type Hidden is access all Integer;
> end Opaque;

I'm sorry but I didn't make it clear enough.  It's more like this:

package Test is
     type Public_Name is limited private;
     function Initialize( File_Name : String ) return Public_Name;
     procedure Process( Input : Public_Name );
private
     type Private_Type is record ... end record;
     type Private_Type_Ptr is access all Private_Type;
     subtype Public_Name is Private_Type_Ptr; -- or what?
end Test;

I don't want to expose the name Private_Type_Ptr because I know that it 
might change in the future.  I know it sounds silly so it's probably 
just poor planning on my part.

To give more specific details as to what I'm doing, I'm trying to return 
a pointer to a node in a tree structure.  There are several types of 
nodes and I'm concerned that in the future I will want to return a 
different type of node.  I want to hide this from the client.

Thank you again,
Ryan

Re: Hiding a type

[sk]

Hi, 

Not sure if this is what you are looking for, but 

package Whatever is

    type Something is private;

    procedure Some_Procedure (Thing : Something);

private

    type Internal_Something;

    type Something is access Internal_Something;

end Whatever;

package body Whatever is

    type Internal_Something is new Integer;
    -- Whatever type you define

    procedure Some_Procedure (Thing : Something) is
    begin
        null;
    end Some_Procedure;

end Whatever;

The item of interest being the incomplete definition of
"Internal_Something" in the package specification.

-- 
-------------------------------------
-- Merge vertically for real address
-------------------------------------
s n p @ t . o
 k i e k c c m
-------------------------------------

Re: Hiding a type

[Frank J. Lhota]

> I don't want to expose the name Private_Type_Ptr because I know that it
> might change in the future.  I know it sounds silly so it's probably
> just poor planning on my part.

It doesn't sound silly, it is always a good idea to hide implementation
details. On the other hand, Private_Type_Ptr as declared in your code
snippet is not exposed, since it appears in the private portion of the Test
package. The only units exposed to the private part of Test is the
cooresponding package body, and any child package of Test. The clients of
Test will not see this definition.

My recommendation would be to skip the definition of Private_Type_Ptr
entirely, and define Public_Name as the access type:

package Test is
     type Public_Name is limited private;
     function Initialize( File_Name : String ) return Public_Name;
     procedure Process( Input : Public_Name );
private
     type Private_Type is record ... end record;
     type Public_Name is access all Private_Type;
end Test;

Re: Hiding a type

[Ryan Tarpine]

Frank J. Lhota wrote:
> My recommendation would be to skip the definition of Private_Type_Ptr
> entirely, and define Public_Name as the access type:
> 
> ...

The idea is that if I have 3 kinds of nodes (N1, N2, N3) with respective 
access types, I can rename one to be the public type (Root).  All 
private functions will take N1_Ptrs, N2_Ptrs, etc.  Only the public 
functions should take a Root.  Maybe N1_Ptr is at first the root type 
but later on another node type N4 is added and now N4_Ptr should be the 
root type.  I want to make sure that all the private functions don't 
have to change; if I had skipped the definition of N1_Ptr and just used 
Root, then my private functions would have to be changed since they 
should not take a Root but instead a pointer to an N1.  They should 
always take the same type regardless of what the root type is.  Whew!  I 
hope that doesn't sound as bad to you as it does to me :)

I did just come up with a small hack, though.  I can define the root to 
be the access type and then *subtype the root type* to make the private 
type.  If the root type changes, I can then modify the private type to 
directly be an access to the original node type.  I'm writing too much 
to explain myself; that means I must be doing something wrong :) It's 
kind of ugly, but it works.

Cheers,
Ryan

Re: Hiding a type

[Frank J. Lhota]

> The idea is that if I have 3 kinds of nodes (N1, N2, N3) with respective
> access types, I can rename one to be the public type (Root).  All
> private functions will take N1_Ptrs, N2_Ptrs, etc.  Only the public
> functions should take a Root.

This is beginning to sound like a case for using tagged types. Please look
into it, you may be able to turn your "kind of ugly" hack into something
beautiful.

Re: Hiding a type

[Simon Wright]

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:

> package Test is
>      type Public_Name is limited private;
>      function Initialize( File_Name : String ) return Public_Name;
>      procedure Process( Input : Public_Name );
> private
>      type Private_Type is record ... end record;
>      type Public_Name is access all Private_Type;
> end Test;

I don't know if this will compile, but it's certainly not possible to
use it; if Public_Name is _limited_ private, clients have no
assignment operation.

Re: Hiding a type

[Frank J. Lhota]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vd6tziy2c.fsf@pushface.org...
> "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:
>
> > package Test is
> >      type Public_Name is limited private;
> >      function Initialize( File_Name : String ) return Public_Name;
> >      procedure Process( Input : Public_Name );
> > private
> >      type Private_Type is record ... end record;
> >      type Public_Name is access all Private_Type;
> > end Test;
>
> I don't know if this will compile, but it's certainly not possible to
> use it; if Public_Name is _limited_ private, clients have no
> assignment operation.

You've got a good point, but what you say is true of any implementation of
Public_Name. One fix would be to make Initialize a procedure, as follows:

package Test is
     type Public_Name is limited private;
     procedure Initialize( Item : in out Public_Name; File_Name : in
String );
     procedure Process( Input : Public_Name );
private
     ...
     type Public_Name is ...;
end Test;

This change is probably necessary irrespective of the implementation of
Public_Name.

Given further clarification by Ryan, I would recommend the following:

package Test is
     type Public_Name is limited private;
     procedure Initialize( Item : in out Public_Name; File_Name : in
String );
     procedure Process( Input : Public_Name );
private
     -- May want to declare the following type as abstract.
     type Private_Root_Type is tagged record ... end record;
     type Public_Name is access all Private_Root_Type'Class;
end Test;

Re: Hiding a type

[Ryan Tarpine]

Frank J. Lhota wrote:
>...
> Given further clarification by Ryan, I would recommend the following:
> 
> package Test is
>      type Public_Name is limited private;
>      procedure Initialize( Item : in out Public_Name; File_Name : in
> String );
>      procedure Process( Input : Public_Name );
> private
>      -- May want to declare the following type as abstract.
>      type Private_Root_Type is tagged record ... end record;
>      type Public_Name is access all Private_Root_Type'Class;
> end Test;
> 

My heartfelt thanks to everyone for all your helpful explanations!  You 
have given me a much better understanding of the situation.  The above 
solution was my favorite, and I plan to use it in my application.

Thanks again,
Ryan

Re: Hiding a type

[Jeffrey Carter]

Simon Wright wrote:
> 
> "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:
> 
> > package Test is
> >      type Public_Name is limited private;
> >      function Initialize( File_Name : String ) return Public_Name;
> >      procedure Process( Input : Public_Name );
> > private
> >      type Private_Type is record ... end record;
> >      type Public_Name is access all Private_Type;
> > end Test;
> 
> I don't know if this will compile, but it's certainly not possible to
> use it; if Public_Name is _limited_ private, clients have no
> assignment operation.

The OP stated that he didn't want the client to create variables of the
type, but instead pass function results to other subprograms. So this
could be used as

Process (Input => Initialize ("File_Name") );

-- 
Jeff Carter
"You couldn't catch clap in a brothel, silly English K...niggets."
Monty Python & the Holy Grail

Re: Hiding a type

[Simon Wright]

Jeffrey Carter <jrcarter@computer.org> writes:

> The OP stated that he didn't want the client to create variables of
> the type, but instead pass function results to other subprograms. So
> this could be used as

So he did, sorry. I liked your renaming idea, too .. (it was yours?
getting confused here)

Re: Hiding a type

[chris.danx]

"Ryan Tarpine" <rtarpine@hotmail.com> wrote in message
news:3D2733F4.8010304@hotmail.com...
> Pat Rogers wrote:
>
> > Do check out a textbook from the library -- it is worth the time -- or
> > take one of the on-line tutorials.  See www.adapower.com.
>
> I hope to get a textbook soon.  I'll have to buy one, as my local
> library is quite small.  I've read most of Ada Distilled and use it as a
> quick reference, and I don't find the reference manual too difficult to
> look through because I've used much more cumbersome languages before
> **ahem**c++**cough**.  The Lovelace tutorial is also wonderful.

Follow the links on adapower and you'll get a link to Ada 95:  the craft of
oo programming by John English.  It's the best textbook, but nowadays you'll
be lucky to get it in a nice bound book, as it has gone out of print
(saturation apparently), but there is an online version so it's not gone
completely and it's free for everyone!


> >>I want to write functions that will return something of type Hide in a
> >>way so clients can't do anything except pass it to other functions.  I
> >>also don't want them to know if I change how I implement it.  (In my
> >>real program, I'm trying to hide that Foo returns an access type.)
> >>Please tell how I should actually do this
> >
> >
> > package Opaque is
> >     type Hidden is limited private;
> >     -- declare the operations here that you want to export to clients
> > private
> >     type Hidden is access all Integer;
> > end Opaque;
>
> I'm sorry but I didn't make it clear enough.  It's more like this:
>
> package Test is
>      type Public_Name is limited private;
>      function Initialize( File_Name : String ) return Public_Name;
>      procedure Process( Input : Public_Name );
> private
>      type Private_Type is record ... end record;
>      type Private_Type_Ptr is access all Private_Type;
>      subtype Public_Name is Private_Type_Ptr; -- or what?
> end Test;
>
> I don't want to expose the name Private_Type_Ptr because I know that it
> might change in the future.  I know it sounds silly so it's probably
> just poor planning on my part.

Does that not do it? If it's right, it won't expose the private_type_ptr to
the world.  The name public_name will hide private_type_ptr.


> To give more specific details as to what I'm doing, I'm trying to return
> a pointer to a node in a tree structure.  There are several types of
> nodes and I'm concerned that in the future I will want to return a
> different type of node.  I want to hide this from the client.

Doesn't the client need to know what type of node they're dealing with in
order to process it?

Re: Hiding a type

[Ryan Tarpine]

chris.danx wrote:
> Follow the links on adapower and you'll get a link to Ada 95:  the craft of
> oo programming by John English.  It's the best textbook, but nowadays you'll
> be lucky to get it in a nice bound book, as it has gone out of print
> (saturation apparently), but there is an online version so it's not gone
> completely and it's free for everyone!
> 

I always prefer to have a hardcopy for flipping through (although 
Mozilla's tabs let me flip between web pages easily, too!), and by a 
stroke of luck it seems that there are some used copies for sale off 
Amazon.com.  I'll probably order a copy before the night's over :)

>>...
>>package Test is
>>     type Public_Name is limited private;
>>     function Initialize( File_Name : String ) return Public_Name;
>>     procedure Process( Input : Public_Name );
>>private
>>     type Private_Type is record ... end record;
>>     type Private_Type_Ptr is access all Private_Type;
>>     subtype Public_Name is Private_Type_Ptr; -- or what?
>>end Test;
>>
>>...
> 
> 
> Does that not do it? If it's right, it won't expose the private_type_ptr to
> the world.  The name public_name will hide private_type_ptr.
> 

It looked correct when I wrote it, but that's not saying much since I 
only have a week of study under my belt :) GNAT tells me

test.ads:2:10: missing full declaration for private type "Public_Name"
test.ads:8:13: "Public_Name" conflicts with declaration at line 2

> 
>>To give more specific details as to what I'm doing, I'm trying to return
>>a pointer to a node in a tree structure.  There are several types of
>>nodes and I'm concerned that in the future I will want to return a
>>different type of node.  I want to hide this from the client.
> 
> 
> Doesn't the client need to know what type of node they're dealing with in
> order to process it?
> 

Not really, since I only want to return the root node of the tree.  All 
public functions will only take whatever type the root node should be. 
As development continues, though, that type might change and another 
type might instead be used for the root.  I only want to have to modify 
to the few public functions.  This is, of course, only speculation in my 
mind and possibly could never happen...

Thanks,
Ryan

Re: Hiding a type

[Jeffrey Carter]

Ryan Tarpine wrote:
> 
> It looked correct when I wrote it, but that's not saying much since I
> only have a week of study under my belt :) GNAT tells me
> 
> test.ads:2:10: missing full declaration for private type "Public_Name"
> test.ads:8:13: "Public_Name" conflicts with declaration at line 2

You should pay attention to compiler messages. These are telling you 2
important things

1. There is no completion for the private type Public_Name
2. You cannot have a subtype with the same name as a type in the same
declarative region.

What you still seem to be missing, although you've been presented with
several examples doing it correctly, is that the completion ("full
declaration" in ARM-speak) of a private type is itself a type
declaration, not a subtype declaration:

package P is
   type T is limited private;
private -- P
   type T is new Integer;
end P;

There is no way in Ada to declare a type for which you cannot declare an
object. Limited private is good, since assignment is not defined for
limited types, and you might also want to add unknown discriminants to
the public view of the type:

type T (<>) is limited private;

Now the client cannot create a variable of the type, but can create a
constant by renaming a function call:

function F return T;
...
V : T renames F;

Another approach may be to use the package-as-object technique. In this
way of doing things, you would declare a generic package with only
subprograms exported. The data is declared in the body of the package.
Each instance of the package becomes an object with the subprograms
acting as the operations on that object.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail

Re: Hiding a type

[Preben Randhol]

Ryan Tarpine <rtarpine@hotmail.com> wrote on 07/07/2002 (02:27) :
> chris.danx wrote:
> >Follow the links on adapower and you'll get a link to Ada 95:  the
> >craft of oo programming by John English.  It's the best textbook, but
> >nowadays you'll be lucky to get it in a nice bound book, as it has
> >gone out of print (saturation apparently), but there is an online
> >version so it's not gone completely and it's free for everyone!
> >
> 
> I always prefer to have a hardcopy for flipping through (although
> Mozilla's tabs let me flip between web pages easily, too!), and by a
> stroke of luck it seems that there are some used copies for sale off
> Amazon.com.  I'll probably order a copy before the night's over :)

I would also recommend "Ada as a second language" by Norman H. Cohen
or "Programming in Ada 95 (2nd Edition)" by  J. G. P. Barnes as they
both cover the whole language.

-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: Hiding a type

[chris.danx]

"chris.danx" <spamoff.danx@ntlworld.com> wrote in message
news:pOKV8.15189$xf3.2097028@news11-gui.server.ntli.net...
>
> Doesn't the client need to know what type of node they're dealing with in
> order to process it?

Or know what to do with a node once it arrives?