private and limited private

private and limited private

[AGBOH CHARLES]

Hi

I would like to the know the difference between private and limited private
types.  What is the criterion for choosing one as opposed to the other.

Instantiation:  what does this mean?

Pardon me but I am learning Ada

Re: private and limited private

[Matthew Heaney]

In article <53dfjn$1u@rc1.vub.ac.be>, cagboh@vub.ac.be (AGBOH CHARLES) wrote:

>I would like to the know the difference between private and limited private
>types.  What is the criterion for choosing one as opposed to the other.
>
>Instantiation:  what does this mean?
>
>Pardon me but I am learning Ada

There is no such thing as a dumb question.

You came to the right place to get Ada questions answered.  The only policy
of this list, especially if you are a student, is that you try to solve the
programming problem first before asking for help, and that you don't ask
readers to solve the problem for you.

"Instantiation" means "create an instance of."  It refers to the
reification of a (real) package from a generic one.  For example,

generic
   type T is private;
package Stacks is

   type Stack is private;

   procedure Push (Item : in T; On : in out Stack);

...
end Stacks;

I don't have a stack type yet, just a template for one.  Suppose I want to
create a stack of, say, integers.  Then I instantiate the generic stack to
create a type from which I can create stack objects that hold Integers.

package body P is

   package Integer_Stacks is new Stacks (Integer);
   subtype Integer_Stack is Integer_Stacks.Stack;

   The_Stack : Integer_Stack;
   use Integer_Stacks;
...
   O : Integer := ...;
begin
   Push (O, On => The_Stack);
...

The instantiatation 

   package Integer_Stacks is new Stacks (Integer);

brings the type Stack into existance.  I'm then allowed to create stack objects.

A private type (limited or non-limited) is Ada's mechanism for allowing the
programmer to create user-defined types, specifically "abstract data
types."  It's not unlike a "class" in C++ or Eiffel.

"Private" refers to the fact that this is an "abstraction," and the details
about how this type is really implemented are hidden.  The Stack type above
is an example.

A "limited" type refers to the fact that assignment and tests of equality
are not available for the type.  For example,

   type Stack is private;

means I can assign stacks to one another:

   X, Y : Integer_Stack;
begin
...
   if Y /= X then
      Y := X;
 ...

I can test for equality and I can assign stacks.

However, sometimes the abstraction requires that assignment not be allowed. 
For example,

   X, Y : Text_IO.File_Type;
begin
...
   Y := X;   -- illegal

Understand that the (Ada) concept of a type is something the describes a
set of values *and* a set of operations.  An abstract data type declaration
- one declared as private - specifies which operations are allowed for
objects of that type.

You may wish to browse these Ada tutorials for more info:

http://www.cs.rmit.edu.au/~dale/ada/aln.html
http://www.swcp.com/~dodrill/adalist.html
http://www.adahome.com/Tutorials/Lovelace/lovelace.html

Hope that answers your question.  Post again if you're still confused.

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: private and limited private

[David Kirkland]

AGBOH CHARLES wrote:
> 
> Hi
> 
> I would like to the know the difference between private and limited private
> types.  What is the criterion for choosing one as opposed to the other.
> 
> Instantiation:  what does this mean?
> 
> Pardon me but I am learning Ada

Say you declare a type as private. When I go to use that type I
can freely use equality and assignment operators as well as any
functions you create to let me manipulate that type. If you declare
the type as limited private, I can no longer use the equality or
asignment operators. I can only use the functions you export to let
me manipulate the type.

In Ada there are generic packages which do nothing by themselves.
The generic packages let you specify the data types and also functions
which the package will use when you instantiate it. An instantiation
creates one instance of a generic package. Once you've instantiated it
you can use it like any other package.

A common application is , say a sorting algorithm. You could 
instantiate it once to create an integer sorting algorithm, and
another instantiation to sort floats. Depending on how you design the
generic you can also pass it the function to use to find out it
one item is larger than another. This is great when you create a 
new data type and you want some special sorting algorithm - say
alphabetically.

Cheers,
Dave

Re: private and limited private

[Samuel Mize]

In article <53dfjn$1u@rc1.vub.ac.be>, AGBOH CHARLES <cagboh@vub.ac.be> wrote:
>
>I would like to the know the difference between private and limited private
>types.  What is the criterion for choosing one as opposed to the other.

A private type is a data type and a set of operations on it.  Only
these operations (defined in the same package) can change it.  Code
outside the package can't access the representation.

However, you can still copy it, and use the built-in equality test.
This is generally OK.  For instance, if you are representing playing
cards, the type might be a record with two fields, one for suit and
one for value.  It makes sense to be able to copy a card value (e.g.,
for the program to remember what card was previously dealt), and to
compare two values to see if they refer to the same card.

A limited type doesn't allow copy or test-for-equality.  Its typical
use is where the data item doesn't just represent a value, but something
that can't be copied.  For instance, file_type in text_io is limited
private.  The one data object represents the one physical connection to
that file.  You aren't allowed to have many copies of the same physical
file descriptor.


>Instantiation:  what does this mean?

Another poster has answered this.  Actually he answered what the
private/limited difference IS, but not WHY it is.


>Pardon me but I am learning Ada

Sam Mize

Re: private and limited private

[John English]

Samuel Mize (smize@imagin.net) wrote:
: [... snip ...]

: However, you can still copy it, and use the built-in equality test.
: This is generally OK.  For instance, if you are representing playing
: cards, the type might be a record with two fields, one for suit and
: one for value.  It makes sense to be able to copy a card value (e.g.,
: for the program to remember what card was previously dealt), and to
: compare two values to see if they refer to the same card.

Actually, playing cards would be better represented by a limited type
with a Move (as opposed to a Copy) primitive, since in the real world
you move cards from A to B, you don't *copy* them.  If you allow
assignment, you allow the creation of as many copies of the Ace of
Spades (or whatever) that you like.  From watching Westerns, I gather
that most people frown on this and fill you with lead/break tables
over your head/whatever if you're caught doing it.

---------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | fax: (+44) 1273 642405
 University of Brighton    |
---------------------------------------------------------------

Re: private and limited private

[Pat Rogers]

In <53vmmb$560@saturn.brighton.ac.uk>, je@bton.ac.uk (John English) writes:
>Samuel Mize (smize@imagin.net) wrote:
[snip]
>Actually, playing cards would be better represented by a limited type
>with a Move (as opposed to a Copy) primitive, since in the real world
>you move cards from A to B, you don't *copy* them.  If you allow
>assignment, you allow the creation of as many copies of the Ace of
>Spades (or whatever) that you like.  From watching Westerns, I gather
>that most people frown on this and fill you with lead/break tables
>over your head/whatever if you're caught doing it.

Yes, it is almost as bad as stealing someone's horse.  (Said with a perfectly
straight face.)

pat
---------------
Patrick Rogers
progers@acm.org

Re: private and limited private

[Samuel Mize]

In article <53vmmb$560@saturn.brighton.ac.uk>,
John English <je@bton.ac.uk> wrote:
>Samuel Mize (smize@imagin.net) wrote:
>: [... snip ...]
>
>: However, you can still copy it, and use the built-in equality test.
>: This is generally OK.  For instance, if you are representing playing
>: cards, the type might be a record with two fields, one for suit and
>: one for value.  It makes sense to be able to copy a card value (e.g.,
>: for the program to remember what card was previously dealt), and to
>: compare two values to see if they refer to the same card.
>
>Actually, playing cards would be better represented by a limited type
>with a Move (as opposed to a Copy) primitive, since in the real world
>you move cards from A to B, you don't *copy* them.

But you can remember which cards have been played* (that's why casinos
use several decks at the Blackjack tables)**.  That's hard to represent
with a limited type -- your "player" program can't make a "mental copy"
of the values it's seen.

>If you allow
>assignment, you allow the creation of as many copies of the Ace of
>Spades (or whatever) that you like.  From watching Westerns, I gather
>that most people frown on this and fill you with lead/break tables
>over your head/whatever if you're caught doing it.

Proof by existence that multiple copies of the same value are possible.

* People do this at Gin Rummy and Bridge, for instance.

** It's called card counting.  It's described in various books, and there's
   probably a blackjack newsgroup.  The move "Rain Man" describes it,
   although the details are wildly inaccurate.

Samuel Mize

Re: private and limited private

[John English]

Samuel Mize (smize@imagin.net) wrote:
: In article <53vmmb$560@saturn.brighton.ac.uk>,
: John English <je@bton.ac.uk> wrote:
: >Actually, playing cards would be better represented by a limited type
: >with a Move (as opposed to a Copy) primitive, since in the real world
: >you move cards from A to B, you don't *copy* them.

: But you can remember which cards have been played* (that's why casinos
: use several decks at the Blackjack tables)**.  That's hard to represent
: with a limited type -- your "player" program can't make a "mental copy"
: of the values it's seen.

You can certainly extract the suit and value of a card, and you could
remember those.  You wouldn't be able to use that information to
manufacture a counterfeit card, any more than remembering what the
Ace of Spades looks like will allow you to materialise one from
behind your ear.

---------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | fax: (+44) 1273 642405
 University of Brighton    |
---------------------------------------------------------------