An Ada9X mimic of C++ friends?

An Ada9X mimic of C++ friends?

[Donald M Needham]

Is there a construct in Ada9x that circumvents data abstraction
similar to a friend in C++?

needham@brc.uconn.edu

Re: An Ada9X mimic of C++ friends?

[David Weller]

In article <3h7u4p$8cp@bellboy.ucc.uconn.edu>,
Donald M Needham <needham@newsserver.uconn.edu> wrote:
>Is there a construct in Ada9x that circumvents data abstraction
>similar to a friend in C++?
>
>needham@brc.uconn.edu
>

To answer the question in a general way, you can achieve it with
child libraries.  However, it's better to ask you to post an example.
FOr instance, because the concept of type and module are separated in
Ada, you don't have to go through the "friend" torture like you do in
C++ (where type(class) and module are (generally) the same).

-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
	

Re: An Ada9X mimic of C++ friends?

[Michel Gauthier]

In article <3h7u4p$8cp@bellboy.ucc.uconn.edu>,
needham@newsserver.uconn.edu (Donald M Needham) wrote:

>>  Is there a construct in Ada9x that circumvents data abstraction
>>  similar to a friend in C++?

"Friends" are patches caused by the lack of essential features that exist
in Ada.
Therefore, I suggest you not to overspecify in C++ spirit.

IMHO, try to ask yourself if you are not in a case where objects
are not the right concept, and where a classic concept of value
would be better to model real world.

-- 
Michel Gauthier - Laboratoire d'informatique - 123 avenue Albert Thomas
F-87060 Limoges - fax +33()55457315
----- Are the messages that objects exchange also objects ? -----

Re: An Ada9X mimic of C++ friends?

[Cyrille Comar]

needham@newsserver.uconn.edu (Donald M Needham) writes:
: Is there a construct in Ada9x that circumvents data abstraction
: similar to a friend in C++?

You can use the private part of a child unit (or a private child) to
more or less simulate C++ friends. I say "more or less" because the
"privacy" in C++ is an attribute of the Class where it is an attribute
of the package in Ada and Ada package ARE NOT to be compared to C++
Classes. The right equivalent to C++ classes in Ada95 are private or
record types (depending on what level of data abstraction you
want). Those types being "tagged" if you expect to need run-time
dispatching or type extension.
-- 
------------------------------------------------------------------------
Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
Gnat Project                                    US phone: (212) 998-3489

Re: An Ada9X mimic of C++ friends?

[John Howard]

Cyrille Comar (comar@cs.nyu.edu) wrote:
: needham@newsserver.uconn.edu (Donald M Needham) writes:
: : Is there a construct in Ada9x that circumvents data abstraction
: : similar to a friend in C++?

: You can use the private part of a child unit (or a private child) to
: more or less simulate C++ friends. I say "more or less" because the
: "privacy" in C++ is an attribute of the Class where it is an attribute
: of the package in Ada and Ada package ARE NOT to be compared to C++
: Classes. The right equivalent to C++ classes in Ada95 are private or
: record types (depending on what level of data abstraction you
: want). Those types being "tagged" if you expect to need run-time
: dispatching or type extension.

: Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
: Gnat Project                                    US phone: (212) 998-3489

I come from a background with Borland Pascal dialects and recently I was 
investigating Extended Pascal (ISO 10206:1991) and the latest 
"Object-Oriented Extensions to Pascal" (ANS TR13 or X3J9/93-033).  With 
Borland Pascal and C++ it was required to indicate in the definition of a 
method whether it could be overridden (e.g. virtual) in a descendant class.

Extended Pascal takes the opposite approach.  According to Appendix D.12 
in X3J9/93-033 "Any visible method can be overridden in a descendant class.
A requirement to specify that a method can be overridden thwarts 
specialization and code refinement.  It also requires an omniscient 
designer who anticipates future use; or, it requires the user must have 
access to the underlying code so that it can be changed.  Both of these 
are poor assumptions."

I am new to Ada.
So my question is: does the explicit use of "TAGGED" in Ada95 have the same 
negative consequences as specifying "virtual"?

Re: An Ada9X mimic of C++ friends?

[Stephane Barbey]

In article <3hcao9$96b@solar.sky.net>, jhoward@solar.sky.net (John Howard) 
: So my question is: does the explicit use of "TAGGED" in Ada95 have the same 
: negative consequences as specifying "virtual"?

No, Ada 83 and Ada 95 take the approach that every primitive operation
(i.e. method) of a tagged type (i.e. a class) can be freely overriden.

The reserved words "virtual" (C++) or "override" (Object Pascal) are
not needed in Ada 95, because dispatching (i.e. dynamic binding) does
not occur on a by-method basis, but on a by-call basis (i.e. the
dispatching calls), thus providing all the power and more flexibility
than typical OO languages.

-Stephane 

--
Stephane Barbey				"It's not easy getting real wings"	
INJ-335, barbey@di.epfl.ch

Re: An Ada9X mimic of C++ friends?

[Norman H. Cohen]

In article <3hcao9$96b@solar.sky.net>, jhoward@solar.sky.net (John Howard)
writes: 

|> I come from a background with Borland Pascal dialects and recently I was
|> investigating Extended Pascal (ISO 10206:1991) and the latest
|> "Object-Oriented Extensions to Pascal" (ANS TR13 or X3J9/93-033).  With
|> Borland Pascal and C++ it was required to indicate in the definition of a
|> method whether it could be overridden (e.g. virtual) in a descendant class.
|>
|> Extended Pascal takes the opposite approach.  According to Appendix D.12
|> in X3J9/93-033 "Any visible method can be overridden in a descendant class.
|> A requirement to specify that a method can be overridden thwarts
|> specialization and code refinement.  It also requires an omniscient
|> designer who anticipates future use; or, it requires the user must have
|> access to the underlying code so that it can be changed.  Both of these
|> are poor assumptions."
|>
|> I am new to Ada.
|> So my question is: does the explicit use of "TAGGED" in Ada95 have the same
|> negative consequences as specifying "virtual"?

Note that "tagged" is specified per type, not per subprogram.  If a type
T is declared tagged, then any subprograms you declare in the same
package with parameters or results of type T will be dispatching
(virtual).  It is also perfectly reasonable in Ada 95 for subprograms in
that package to have parameters of type T'Class rather than T, in which
case they are not dispatching.  This is appropriate if the specifications
of the subprogram can be fulfilled using only properties common to all
types in the class.  These properties include the components declared at
the root of the class and other, possibly dispatching, subprograms
defined for all types in the class.  One need not be "omniscient" to
write a classwide subprogram that will work correctly for all present and
future subclasses.

(Example: Consider an abstract tagged type for mappings from integers to
integers, with a dispatching function Value_At that takes a mapping and
an integer and returns the value of that mapping at that integer.  There
may be several concrete extensions implementing mappings as arrays of
mapping values indexed by argument values, as linear lists of
argument-value pairs, and as hash tables, for example, each with a
different implementation of Value_At.  A classwide function
Value_Of_Composition_At, taking two mappings and an integer and returning
the value of the composition of the two mappings at that integer, can be
written as follows: 

   function Value_Of_Composition_At
      (Second, First: Mapping_Type'Class; Argument: Integer)
      return Integer is
      Intermediate_Result: Integer;
   begin
      Intermediate_Result := Value_At (First, Integer);
      return Value_At (Second, Intermediate_Result);
   end Value_Of_Composition_At;

Because of the two dispatching calls on Value_At--each of which may
dispatch to a different version--Value_Of_Composition_At will continue to
work for all kinds of mappings, even as new extensions of Mapping_Type
with their own Value_At functions are added to the system.)

I am not familiar with the OO extensions to Pascal, but I assume that
only entities declared as classes have overridable operations.  I presume
it is still possible to declare scalar types, record types, and array
types acted upon by subprograms that are not overridable.  The situation
is the same in Ada.  Declaring a type to be tagged is analogous to
declaring an OO Pascal type to be a class rather than an ordinary record
type.

It would, of course, be a major efficiency hit to require that all types
be extendable and all operations be overridable.  (Imagine viewing each
char in a string as an object, with its own dispatching-table pointer!)
The X3J9/93-033 language about "thwarting specialization and code
refinement" seems to presume that all programmers embrace the OO
paradigm.  Not all programmers do.  Ada 95 makes it easy, but not
mandatory, to do things in an OO style.  Programmers who choose to forego
the flexibility and maintainability promised by OOP advocates in return
for efficiency can do so by eschewing tagged types.  They can still
benefit from the use of a package as a module.

Of course it's not a black-and-white issue.  A reasonably designed
program may contain a mixture of OOP and non-OOP approaches.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: An Ada9X mimic of C++ friends?

[Cyrille Comar]

jhoward@solar.sky.net (John Howard) writes:
: designer who anticipates future use; or, it requires the user must have 
: access to the underlying code so that it can be changed.  Both of these 
: are poor assumptions."
: 
: I am new to Ada.
: So my question is: does the explicit use of "TAGGED" in Ada95 have the same 
: negative consequences as specifying "virtual"?

Being obliged to specify "virtual" in C++ is not 100% negative. It has
an impact on code generation (a non-virtual function call is more
efficient than a virtual function call).

Anyway the Ada95 approach is different. All subprograms defined
"reasonably close to the type definition" (I won't try to give the
formal definition here :-) are primitive, i.e. virtual in the C++
sense and can be overridden by descendants. In the other hand the
notion of Class-Wide type (which doesn't exist in C++) allows the
compiler to know if the  call to a primitive operation is dispatching
or not so you only pay for dispatching when you actually use it. I
have been told that some C++ compilers were able to optimize calls to
virtual functions that are obviously not dispatching but the C++
typing mechanism doesn't give much room for this kind of
optimizations...
 
-- 
------------------------------------------------------------------------
Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
Gnat Project                                    US phone: (212) 998-3489

Re: An Ada9X mimic of C++ friends?

[Dave Papay M/S 7G32 x2791]

Donald M Needham <needham@NEWSSERVER.UCONN.EDU> write:
>
>Is there a construct in Ada9x that circumvents data abstraction
>similar to a friend in C++?
>
>needham@brc.uconn.edu

An Ada95 child package has visibility to the private part of its parent,
thus "circumventing" the data abstraction created by private types.  An
interesting difference is that in C++, a class declares who its fiends are,
while in Ada95, a package declares itself as a child of the parent.

There are both public and private children.  In a public child, the information
in the private part of the parent is only visibile in the private part (and
corresponding package body, if any) of the child.  Thus, the public child
cannot "export" this information.

In a private child, the information in the private part of the parent is
visible in all places.  However, private units cannot be 'with'ed outside of
the hierarchy rooted at the parent unit, so they too cannot export this
information.

This explanation is not precise, and is off the top of my head, so I'm sure
I've missed many of the finer details.  But it does cover the basic ideas,
and will give you a good starting point to work with.

                             |         |
David Papay                  |    o    |
papay@acm.org  (preferred)   |  ^/---  |    insert your favorite
dpapay@aol.com (alternate)   |  />     |      disclaimer here
                             |         |
                             | fleche! |