CVS difference for ai05s/ai05-0060-1.txt

--- ai05s/ai05-0060-1.txt	2008/02/05 02:18:02	1.6
+++ ai05s/ai05-0060-1.txt	2008/02/05 02:33:25	1.7
@@ -1,4 +1,4 @@
-!standard E.2(14)                                      08-02-01    AI05-0060-1/03
+!standard E.2(14)                                      08-02-04    AI05-0060-1/04
 !standard E.2.2(9/1)
 !standard E.2.2(9.2/1)
 !standard E.2.2(14/2)
@@ -29,6 +29,9 @@
 The value of a remote access-to-class-wide limited interface type can be
 an object of a nonlimited type derived from the interface type.
 
+The use of remote access-to-class-wide interface types is recommended over
+the use of other remote access-to-class-wide types.
+
 !question
 
 (1) E.2.2(9-9.2/1) define what a remote access type can designate. This does not include
@@ -48,8 +51,17 @@
 it disallows accessing components directly. If this rule enforces that remote access
 is limited and private in nature, should we allow remote access types to designate 
 all class-wide types? (Maybe, but if so, this should be dealt with in a separate AI)
+
+(4) Assuming we allow remote access-to-class-wide limited interface types, these types
+could be used in place of any other existing usages for remote access-to-class-wide types.
+Remote access types are really providing access to no more than the interface of an object.
+Should we recommend that remote access-to-class-wide types be use to designate only
+limited interface types? (Yes.) If so, should we formally say that the use of remote 
+access-to-class-wide types that designate objects other than limited interface types is
+obsolescent in Annex J? (Maybe, but as this affects a different annex than the rest of 
+the changes, that should be dealt with in a separate AI, if necessary)
 
-(4) The definition of remote access types includes any anonymous access types that occur
+(5) The definition of remote access types includes any anonymous access types that occur
 visibly in the remote types package. But such anonymous access types are necessarily
 part of another construct (access discriminants, access parameters, access components);
 they will not themselves be used remotely unless the containing construct is. But this
@@ -61,7 +73,7 @@
 
 Should this restriction be relaxed? (Yes.)
 
-(5) Should we formally say that Annex E pragmas have no effect on implementations that
+(6) Should we formally say that Annex E pragmas have no effect on implementations that
 don't support Annex E? (Yes.) Doing so would allow us to declare additional packages to have
 Remote_Types pragmas, as we wouldn't have to worry about the effect on most
 implementations.
@@ -109,7 +121,7 @@
    * The primitive subprograms of the corresponding specific type shall not be
      implemented by protected subprograms or entries.
 
-Add three new paragraphs after E.2.2(18)
+Add four new paragraphs after E.2.2(18):
 
    6 Anonymous access types may be used as access discriminants, access parameters,
    and access components of remote types, but they themselves cannot be used remotely
@@ -117,8 +129,15 @@
 
    7 The value of a remote access to class-wide limited interface can be an object
    of a nonlimited type derived from the interface.
+
+   8 Remote access types allow no more than the interface of an object to be accessed
+   remotely. A remote access-to-class-wide limited interface type can be used anywhere
+   other remote access-to-class-wide types can be used, and better represents the 
+   remote access capability that is being allowed. Therefore it is recommended that
+   remote access-to-class-wide types be used to designate class-wide limited
+   interface types rather than other class-wide limited types.
 
-   8 A remote access type may be a class-wide synchronized interface type, a 
+   9 A remote access type may be a class-wide synchronized interface type, a 
    class-wide protected interface type, or a class-wide task interface type, since
    these interface types are limited interface types.
 
@@ -178,12 +197,15 @@
 so long as the E.2.2(16/1) rule is upheld. This rule would ensure that the 
 object designated by the remote access type can only be accessed as though it
 were limited and private. That is, the object could not be assigned and its
-components cannot be directly accessed remotely. This would be a more radical
-change however, and should perhaps be considered in a separate AI. This AI just
-relaxes the restriction enough to allow remote access types to designate
-limited interface types, which adds maximum remote access capability for the
-minimal amount of change to the RM.
+components cannot be directly accessed remotely.
 
+Such a change would be a bigger change to the language however, and there are
+no known use cases that demonstrate a need for this capability that could not
+be covered by using a remote access-to-class-wide limited interface type.
+Therefore, it has been concluded that the restrictions for remote access types
+should not be relaxed any further than to just allow remote access-to-class-wide
+limited interface types.
+
 The other main difference between a value of a limited interface and a value of a
 limited private tagged type is that the value of a limited interface can designate
 a protected type or a task type, since synchronous interfaces, task interfaces,
@@ -233,25 +255,14 @@
 Since most anonymous access types are only intended to be used locally,
 limiting remote access types to be only named access types provides a clean way
 to distinguish usages.
-
-The final point is that E.2.2(14/2) rules out passing remote access types as
-parameters to other remote access types. This seems unintentional as it would
-be useful to pass handles to objects around remotely to allow dynamic objects to
-call each other. For example a peer to peer system could be setup where
-various remote objects could register with a central server using an RCI package.
-The central server could act as a switchboard, connecting client objects to each
-other by calling primitive registration subprograms of the objects passing in a
-cached handle to the other peer as a remote access type. To allow such usage,
-E.2.2(14/2) needs to be relaxed to allow remote access type parameters to be passed
-as non-controlling formal parameters to primitive subprograms of a remote
-access-to-class-wide type.
 
-Overall, being able to use limited interfaces as remote access types seems like a
-useful capability that can be added to the language with a relatively low level
-of effort. This AI may pave the way for future capabilities such as remote entry
-calls, and remote requeue which might give Ada a further advantage over
+Overall, being able to use limited interfaces as remote access types seems like
+a useful capability that can be added to the language with a relatively low
+level of effort. This AI may pave the way for future capabilities such as remote
+entry calls, and remote requeue which might give Ada a further advantage over
 other languages. It may be that using limited interfaces as remote access types
-could become the preferred way to do remote calls.
+could become the preferred way to do remote calls since typically there are
+synchronization needs associated with remote access type usage.
 
 -- !corrigendum E.2.2(9/1)
 
@@ -1131,5 +1142,37 @@
 interfaces in this case, because they're really what is being implemented
 remotely (an interface, nothing more). The existing cases are essentially
 the implicit creation of a remote limited interface for the designated type.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Saturday, February 2, 2008  6:37 PM
+
+> I think Tuck's point was that you could add a limited interface to such a
+> non-limited type without doing any other changes to the type. 
+ 
+Good point. I agree.  I do not see any use cases that could not be covered by using a 
+remote access to limited interface type.
+ 
+> Indeed, if we were doing this from scratch, it would make sense to allow
+> *only* limited interfaces in this case, because they're really what is being implemented
+> remotely (an interface, nothing more). 
+ 
+ This raises another question. 
+ 
+If we want to recommend that remote access-to-class-wide types should designate
+limited interface types in Ada 2005, should we change the wording so that
+previously allowed remote access to class-wide limited private types or
+class-wide private extensions are obsolescent features described in Annex J?
+ 
+If we want to recommend the use of limited interface types, this might make it clearer
+that  the previous uses should no longer be needed in Ada 2005
+ 
+Regardless whether Annex J is involved, I think it probably makes sense that
+a note be added to Annex E to recommend limited interface types over other
+remote access-to-class-wide types for Ada 2005.
+ 
+I will assume that if changes should be made to Annex J, that those would be
+best covered in a separate AI, unless I hear otherwise.
 
 ****************************************************************