!standard E.2.2 (09) 99-08-31 AI95-00164/04 !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; -- 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; 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 in this AI: * 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) @drepl An access type declared in the visible part of a remote types or remote call interface library unit is called a @i. Such a type shall be either an access-to-subprogram type or a general access type that designates a class-wide limited private type. @dby An access type declared in the visible part of a remote types or remote call interface library unit is called a @i. Such a type shall be either an access-to-subprogram type or a general access type that designates a class-wide limited private type or a class-wide private type extension whose ancestors are private type extensions and a limited private type. !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 ... 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. ****************************************************************