Version 1.13 of ais/ai-00164.txt

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

!standard E.2.2 (09)          00-04-11 AI95-00164/06
!class binding interpretation 96-10-04
!status Corrigendum 2000 99-07-27
!status WG9 approved 99-06-12
!status ARG approved (7-0-0) 98-10-09
!status work item 98-10-02
!status received 96-10-04
!priority High
!difficulty Easy
!qualifier Omission
!subject Definition of remote access type
!summary
E.2.2(9) is interpreted to permit a remote access-to-class-wide type to designate a class-wide private extension of a limited private type.
!question
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;
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;
Also, while limitedness of the target type is clearly needed, there seems to be no reason why the target type needs to be private.
!recommendation
(See summary.)
!wording
Add the following phrase to the end of the second sentence of paragraph E.2.2(9): "or a class-wide private type extension whose ancestors are private type extensions and a limited private type."
!discussion
There were two issues raised:
* application of RACW to private extension of limited private type
* 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.
Retaining the restriction that this paragraph apply to only private types (and their extensions) ensures the least surprise to developers when non-distributed software modules are subsequently inserted into a distributed environment.
!corrigendum E.02.02(9)
Replace the paragraph:
An access type declared in the visible part of a remote types or remote call interface library unit is called a remote access type. Such a type shall be either an access-to-subprogram type or a general access type that designates a class-wide limited private type.
by:
An access type declared in the visible part of a remote types or remote call interface library unit is called a remote access type. Such a type shall be:
!ACATS test
Create a C-Test to check that the example given here works.
!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

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

From: 	Anthony Gargaro
Sent: 	Monday, April 06, 1998 3:56 PM
To: 	Erhard Ploedereder
Cc: 	arg95@sw-eng.falls-church.va.us
Subject: 	Re: [kamrad@blaze-net.com: ai-164]

Dear All-

I am puzzled by this summary. While I do not object to the interpretation
it is not consistent with what was concluded as a result of the discussion
at the Henley meeting of April 11 1987. Reviewing the minutes of the
November meeting in St. Louis I see no indication that there has been
further discussion.

Mike can you clarify what inputs you used to prepare the summary.
Unfortunately, I have not been carefully following ARG correspondence for
the last year so I may have missed something.

Anthony.

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

From: 	Anthony Gargaro
Sent: 	Sunday, February 07, 1999 8:57 AM
Subject: 	Re: AI-164, editorially revised

>!wording 99-02-04

>Add the following phrase to the end of the second sentence of paragraph
>E.2.2(9): "or a class-wide private type extension whose ancestors are
>private type extensions and a limited private type."

The wording "and a limited private type" should read "of a limited
private type."

Anthony.

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

From: 	Erhard Ploedereder
Sent: 	Monday, February 08, 1999 5:28 AM
Subject: 	Re: AI-164, editorially revised

>>!wording 99-02-04

>>Add the following phrase to the end of the second sentence of paragraph
>>E.2.2(9): "or a class-wide private type extension whose ancestors are
>>private type extensions and a limited private type."

> The wording "and a limited private type" should read "of a limited
> private type."

No. The point is that the whole chain of type extensions needs to be
private and the ultimate ancestor needs to be a limited private type.
The above was the shortest way to cover that all the ancestors need
to be private.

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


Questions? Ask the ACAA Technical Agent