Version 1.1.1.1 of ais/ai-00164.txt

Unformatted version of ais/ai-00164.txt version 1.1.1.1
Other versions for file ais/ai-00164.txt

!standard E.2.2 (09)          98-04-01 AI95-00164/01
!class confirmation 98-04-01
!class binding interpretation 96-10-04
!status received 96-10-04
!priority High
!difficulty Easy
!subject Definition of remote access type
!summary 98-04-01
E.2.2(9) can be interpreted to permit a remote access to class wide (RACW) type to designate a class-wide private extension of limited private type.
!question 98-04-01
An interpretation of E.2.2(9) would deny object-oriented programming methodology to distributed Ada programmers by not permitting a remote access to class wide (RACW) type to designate a class-wide private extension of limited private type. If this interpretation holds then the following example is illegal:
package RT is
pragma Remote_Types;
type Root_Object is abstract tagged limited private;
type New_Object is new Root_Object with private;
-- Primitive dispatched procedures of New_Object.
procedure Operation_1 (Obj : access New_Object; Z : Integer);
private type Root_Object is abstract tagged limited null record;
type New_Object is new Root_Object with null record;
end RT;
-- RCI.ads
with RT;
package RCI is
pragma Remote_Call_Interface;
type New_Access is access all RT.New_Object'Class; -- ^^^^^^^^^^ -- illegal
procedure Register (new_obj : New_Access); end;
!recommendation 98-04-01
(See summary.)
!wording 98-04-01
!discussion 98-04-01
There were two issues raised in this AI: =B7 application of RACW to private extension of limited private type =B7 removal of restriction on RACW to private types
Regarding the first issue, the intent of E.2.2(9) is not to exclude private extensions. The conclusion that E.2.2(9) denies distributed object programming seems unwarranted given that typically the designated type is most naturally extended in the body of a package where the distributed/remote object is declared.
Regarding the second issue, if E.2.2(9) is relaxed to allow the type to be completed in the visible part of the package this would provide additional capability only to those objects that are to be accessed locally. Thus, there is no significant gain in a distributed application. The requirement that the designated type of the remote access-to-class-wide type be limited private is consistent with that placed upon a file type since in each case they both provide a handle to some external object.
!appendix

!section E.2.2(09)
!subject Definition of remote access type
!reference RM95-E.2.2(9)
!from Ron Theriault
!keywords remote access objects OOP
!reference 96-5701.a Ron J Theriault  96-9-18>>
!discussion

   The interpretation of E.2.2(9) should be relaxed significantly.
At minimum it should allow private extensions of a class-wide limited
private type to be designated by remote access types.  The current
interpretation denies object oriented programming methodology to
distributed Ada programmers.  A short example is included.

   package  RT  is

      pragma Remote_Types;

      type  Root_Object is abstract tagged limited private;

      type  New_Object is new Root_Object with private;

      --  Primitive dispatched procedures of New_Object.

      procedure Operation_1 (Obj : access New_Object; Z : Integer);

   private
      type  Root_Object is abstract tagged limited  null record;

      type  New_Object is new Root_Object with  null record;

   end RT;

   --  RCI.ads

   with  RT;

   package RCI is

       pragma Remote_Call_Interface;

       type  New_Access is access all RT.New_Object'Class;
       --    ^^^^^^^^^^
       --     illegal

       procedure  Register (new_obj : New_Access);
   end;



   As has been pointed out by T. Taft and A. Gargaro, consideration might
also be given as to whether the type designated by a remote access type
needs to be private at all.  See attached.

    >From stt@dsd.camb.inmet.com Fri Sep 13 15:57 EDT 1996

    The point of making it private is so that no direct component
    access can be performed.  So long as the type is a private extension
    of a private extension of ... a private type, then that goal would be
    accomplished.  In fact, given E.2.2(13) which disallows any dereference
    except as part of a dispatching call, I suppose even requiring it to
    be private is overkill, since any reference to a component would
    violate E.2.2(13).

    -Tuck

    From abg@SEI.CMU.EDU Sat Sep 14 13:56:23 1996
    From: Anthony Gargaro <abg@SEI.CMU.EDU>

    ...  If I recall correctly, the dereferencing rule was introduced
    subsequent to the private type requirement when it was realised
    that dereferencing a remote value as the controlling operand
    of a local dispatching call would create a problem.

    Anthony.



****************************************************************

!section E.2.2(09)
!subject Definition of remote access type
!reference RM95-E.2.2(9)
!reference 96-5701.a Ron Theriault 96-9-18
!from Anthony Gargaro 96-9-19
!keywords remote access objects OOP
!reference 96-5702.a Anthony Gargaro  96-9-19>>
!discussion

>   The interpretation of E.2.2(9) should be relaxed significantly.
>At minimum it should allow private extensions of a class-wide limited
>private type to be designated by remote access types.  The current
>interpretation denies object oriented programming methodology to
>distributed Ada programmers.  A short example is included.

The intent of E.2.2(9) is not to exclude private extensions.

However, the conclusion that E.2.2(9) denies distributed object programming
seems unwarranted given that typically the designated type is most naturally
extended in the body of a package where the distributed/remote object is
declared.

The requirement that the designated type of the remote access-to-class-wide
type be limited private is consistent with that placed upon a file type
since in each case they both provide a handle to some external object.

If E.2.2(9) is relaxed to allow the type to be completed in the visible
part of the package this would provide additional capability only to
those objects that are to be accessed locally. Thus, there is no significant
gain in a distributed application.

(Note that Java RMI is similar to Annex E in this respect. The remote
interface specifies the methods to be implemented by the remote object
and the remote object class specifies the data to be acted upon.)

>   As has been pointed out by T. Taft and A. Gargaro, consideration might
>also be given as to whether the type designated by a remote access type
>needs to be private at all.  See attached.

My observation was only meant to add some historical perspective on how the
specification evolved. Unfortunately, I have been unable to locate a version
of the Annex (ca 1992) where the limited private restriction was specified
without the dereferencing rule.



****************************************************************

!section E.2.2(09)
!subject Definition of remote access type
!reference RM95-E.2.2(9)
!from Ron Theriault
!keywords remote access objects OOP
!reference 96-5718.a Ron J Theriault  96-10-4>>
!discussion

It may be true that one can extend a base type designated by a
remote access-to-class-wide type, by adding new record components
to the type, and still remotely access the derived type.
However one cannot extend such a base type by adding operations
to it, and still use an RACW type to access it.

Since one cannot fully use type extensions in a distributed program,
OOP methodology is not fully applicable to distributed programs.

Additionally, the whole idea of reducing the functionality of a derived
type, from that of the base type (as E.2.2(9) does), seems to run
counter to the OOP paradigm.

See also:
    reference 96-5701.a Ron Theriault 96-9-18
    reference 96-5702.a Anthony Gargaro  96-9-19

****************************************************************

!section E.2.2(09)
!subject Definition of remote access type
!reference RM95-E.2.2(9)
!from Ron Theriault
!keywords remote access objects OOP
!reference 96-5718.a Ron J Theriault  96-10-4>>
!discussion

It may be true that one can extend a base type designated by a
remote access-to-class-wide type, by adding new record components
to the type, and still remotely access the derived type.
However one cannot extend such a base type by adding operations
to it, and still use an RACW type to access it.

Since one cannot fully use type extensions in a distributed program,
OOP methodology is not fully applicable to distributed programs.

Additionally, the whole idea of reducing the functionality of a derived
type, from that of the base type (as E.2.2(9) does), seems to run
counter to the OOP paradigm.

See also:
    reference 96-5701.a Ron Theriault 96-9-18
    reference 96-5702.a Anthony Gargaro  96-9-19

****************************************************************

Questions? Ask the ACAA Technical Agent