CVS difference for ai05s/ai05-0060-1.txt
--- ai05s/ai05-0060-1.txt 2008/01/31 03:02:19 1.5
+++ ai05s/ai05-0060-1.txt 2008/02/05 02:18:02 1.6
@@ -1,4 +1,4 @@
-!standard E.2(14) 08-01-30 AI05-0060-1/02
+!standard E.2(14) 08-02-01 AI05-0060-1/03
!standard E.2.2(9/1)
!standard E.2.2(9.2/1)
!standard E.2.2(14/2)
@@ -23,23 +23,33 @@
but they themselves cannot be used remotely except within the context of
the containing construct.
-Remote access types can be non-controlling formal parameters to primitive
-subprograms of other remote access to class-wide types.
+Remote access types should be allowed to designate class-wide limited interface
+types (including synchronous, task, and protected interface types).
-Class wide access to limited interfaces (including synchronous, task,
-and protected interfaces) should be allowed as remote access types.
+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 value of a remote access to class-wide limited interface can be
-an object of a nonlimited type derived from the interface.
-
!question
(1) E.2.2(9-9.2/1) define what a remote access type can designate. This does not include
a class-wide interface. But an interface is very similar to an abstract tagged limited
private type; neither can have visible components. A class-wide limited private type
is allowed in a remote access type. Shouldn't a limited interface be allowed?
+
+(2) It is possible to derive a nonlimited type from a limited interface type.
+If remote access types are allowed to designate class-wide limited interface types,
+should we allow the value of a remote access-to-class-wide limited interface type to
+be a nonlimited object? (Yes.)
+
+(3) E.2.2(16/1) states that remote access types cannot be dereferenced except through
+dispatching calls. This would be the rule that would allow the value of a remote
+access-to-class-wide limited interface type to be an object of a nonlimited type.
+This rule also enforces the object to be treated as though it is a private type, since
+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)
-(2) The definition of remote access types includes any anonymous access types that occur
+(4) 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
@@ -49,19 +59,13 @@
only remote subprograms, even though the subprogram that is using the parameter is not
itself a remote subprogram.
-Should this restriction be relaxed?
+Should this restriction be relaxed? (Yes.)
-(3) Should we formally say that Annex E pragmas have no effect on implementations that
-don't support Annex E? Doing so would allow us to declare additional packages to have
+(5) 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.
-(4) E.2.2(14/2) states that access parameters are only allowed for the primitive
-subprograms of a remote access to class-wide types if they are controlling parameters,
-yet it seems to be useful to have non-controlling formal parameters that are remote access
-types to allow peer to peer systems. Should we allow remote access types to be passed as
-parameters to subprograms declared in Remote Types Library units? (Yes.)
-
!recommendation
(See Summary.)
@@ -97,8 +101,8 @@
* The primitive subprograms of the corresponding specific [limited private]
type shall only have access parameters if they are controlling formal
- parameters {or remote access type parameters}; each non-controlling
- formal parameter shall support external streaming (see 13.13/2);
+ parameters; each non-controlling formal parameter shall support external
+ streaming (see 13.13/2);
Add a new paragraph after E.2.2(14/2):
@@ -154,11 +158,11 @@
interface does not have any visible components and is a tagged type. One main
difference is that it is possible to derive a nonlimited type from a limited
interface while it is not possible to derive a nonlimited type from a limited
-type. If remote access types are allowed to designate limited interface types,
-then this would mean that the value of a remote access to class-wide limited
+type. If remote access types are allowed to designate limited interface types,
+then this would mean that the value of a remote access to class-wide limited
interface can be an object of a nonlimited type derived from the interface. The
remote (client) view view of the object would still be the equivalent of a
-limited view however, because of rule E 2.2 16/1 which states that a value
+limited view however, because of rule E 2.2(16/1) which states that a value
of a remote access-to-class-wide type shall be dereferenced (or implicitly
converted to an anonymous access type) only as part of a dispatching call where
the value designates a controlling operand of the call. The local (server) view
@@ -167,6 +171,19 @@
could be assigned a new value locally. This capability seems to be potentially
useful and no issues could be found with allowing such usage.
+Since we are now saying that a remote access type can designate a nonlimited
+object, we need to ask whether it makes sense for remote access types to
+designate class-wide nonlimited private types and nonlimited interface types, or
+even more generally, any class-wide types. It seems like this could be workable,
+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.
+
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,
@@ -239,9 +256,10 @@
-- !corrigendum E.2.2(9/1)
-
!ACATS Test
+Add ACATS C-tests to check that limited interfaces are supported here.
+
!appendix
From: Brad Moore
@@ -1015,5 +1033,103 @@
idea: I would think that it would be best to have only one type of remote
"handle"; having a bunch of anonymous ones and converting between them
surely would add complications without an obvious benefit.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, February 1, 2008 10:40 AM
+
+>> * The primitive subprograms of the corresponding specific [limited private]
+>> type shall only have access parameters if they are controlling formal
+>> parameters {or remote access type parameters}; each non-controlling
+>> formal parameter shall support external streaming (see 13.13/2);
+>
+> This change doesn't make sense. An access parameter is always an anonymous
+> access (sub)type (parameters of named access types are *not* access
+> parameters, see 6.1(24/2) for the formal definition of "access parameter".
+
+You are right. I misread the sentence to mean any access parameter type,
+including named and anonymous access types. To get the meaning I was
+thinking of, I believe the sentence would have had to have specifed
+"access type parameters" instead of "access parameters".
+That is pretty subtle. I wonder if it would be helpful in the AARM HTML
+version if references to "access parameter"s could be hyperlinked to where
+the term is defined. That might have avoided the confusion in my case.
+
+The added clause, "or remote type parameters" above should be removed from
+the proposed wording changes. I have removed my added question and related text
+from AI05-0060.
+
+> I suppose you could allow anonymous access types to *be* remote access types
+> in very limited circumstances (presumably only for access-to-classwide), but
+> that would need very different wording. And it's not clear that it is a good
+> idea: I would think that it would be best to have only one type of remote
+> "handle"; having a bunch of anonymous ones and converting between them
+> surely would add complications without an obvious benefit.
+
+I tend to agree. It seems cleaner and simpler to just say that remote access
+types must be named access types.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, February 1, 2008 10:57 AM
+
+Since we are now saying that a remote access type can designate a nonlimited
+object, we need to ask whether it makes sense for remote access types to
+designate class-wide nonlimited private types and nonlimited interface types,
+or even more generally, any class-wide types. It seems like this could be
+workable, 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.
+
+E.2.2(16/1) states that remote access types cannot be dereferenced except through
+dispatching calls. This would be the rule that would allow the value of a remote
+access-to-class-wide limited interface type to be an object of a nonlimited type.
+This rule also enforces the object to be treated as though it is a private type, since
+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?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, February 1, 2008 1:50 PM
+
+Why not just use remote access-to-limited-classwide
+interface? I would rather not have the rules
+for remote access types diverge any more than
+necessary from those for normal access types.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Friday, February 1, 2008 2:44 PM
+
+That was my thought as well, which is why my current wording that
+I submitted to Randy earlier today suggests that though this is a
+possibility, it should be dealt with in a separate AI, if at all.
+The approach taken in AI05-0060 is to get maximum capability with
+minimal wording changes. (Best bang for the buck)
+
+I suppose one reason for adding this capability might be for added
+flexibility. Someone might have some pre-existing nonlimited types and
+suddenly decide they want to use remote access with these types, without
+having to change the types to be limited, which might be a lot of maintenance
+work for a pre-existing system.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, February 1, 2008 3:20 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. Then you could
+use the limited interface to represent the remote access 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). The existing cases are essentially
+the implicit creation of a remote limited interface for the designated type.
****************************************************************
Questions? Ask the ACAA Technical Agent