Version 1.11 of ais/ai-00335.txt
!standard 03.09.02 (01) 05-11-23 AI95-00335/05
!class binding interpretation 03-07-30
!status Amendment 200Y 04-07-02
!status WG9 approved 04-11-18
!status ARG Approved 6-0-0 04-06-14
!status work item 04-04-02
!status received 03-04-23
!qualifier Omission
!priority Low
!difficulty Medium
!subject Stream attributes may be dispatching subprograms
!summary
A stream-oriented attribute of a specific tagged type T is a dispatching
subprogram in the circumstances when this attribute is available for all
descendants of T.
!question
Are stream attributes of tagged types dispatching? (Yes.)
The stream attributes as applied to tagged types do not appear to be
treated as dispatching operations, since they don't fall into the
categorization of being primitive subprograms by the rules in 3.2.3.
However, the semantics of 'Class'Output is defined to make a dispatching
call to 'Output. Shouldn't a user-defined 'Class'Output be able to make the
same call? (Yes.)
!recommendation
(See wording.)
!wording
[Note: This wording assumes that the term "declaration list" is defined as
in AI-420, and the wording updates of AI-260-2.]
Change the first sentence of 3.9.2(1) as follows:
The primitive subprograms of a tagged type{,}[ and] the subprograms declared by
formal_abstract_subprogram_declarations{, and the stream attributes of a
specific tagged type that are available (see 13.13.2) at the end of the
declaration list where the type is declared} are called dispatching operations.
AARM Note: For a type declared immediately within a package_specification which
has a partial view, the declaration list to consider is the visible
part of the package.
End AARM Note.
!discussion
It seems reasonable for a user to want to make a dispatching call to one of the
stream-oriented attributes of type T, especially in the body of a user-defined
stream-oriented attribute of T'Class. After all, the predefined T'Class does
such a dispatching call, and we want to limit the amount of magic that is going
on in these predefined attributes (we know that we cannot entirely eliminate
that magic).
The best solution seems to be to explicitly declare that stream-oriented
attributes of specific types are dispatching subprograms of the type.
Note that we already have dispatching subprograms that are not primitive
in the form of abstract formal subprograms (see AI-260-2), so it is fine to
say this for these as well.
We must be cautious, though, for two reasons:
1 - If T is limited, (some of) its stream-oriented attributes may not be
available.
2 - Because we are going to do a dispatching call, we must ensure that the
attribute is available for T and all of its descendants.
This is a situation quite similar to the one considered in item #3 of AI-195,
where we were trying to determine under which circumstances a stream-oriented
attribute of T'Class is available, given that such an attribute makes a
dispatching call to the corresponding attribute of T. So we can essentially
borrow the words of AI-195.
Note that, because the attribute_definition_clauses for T always occur before T
is frozen, implementations should have no problem adding the appropriate
stream-oriented attributes to the dispatch tables, just like they add ordinary
dispatching subprograms.
There is a small bug in AI-195: the discussion of item #5 has the parenthetical
comment: "(stream-oriented attributes are always called in a non-dispatching
manner)". This comment was never true (precisely because the predefined
attributes of T'Class make a dispatching call to the corresponding attribute of
T) but it is even falser now. It should read "(stream-oriented attributes are
sometimes called in a non-dispatching manner)".
!corrigendum 3.9.2(1)
Replace the paragraph:
The primitive subprograms of a tagged type are called dispatching
operations. A dispatching operation can be called using a statically
determined controlling tag, in which case the body to be executed is
determined at compile time. Alternatively, the controlling tag can be
dynamically determined, in which case the call dispatches to a body that is
determined at run time; such a call is termed a dispatching call. As
explained below, the properties of the operands and the context of a particular
call on a dispatching operation determine how the controlling tag is
determined, and hence whether or not the call is a dispatching call. Run-time
polymorphism is achieved when a dispatching operation is called by a
dispatching call.
by:
The primitive subprograms of a tagged type, the subprograms declared by
formal_abstract_subprogram_declarations, and the stream attributes of a
specific tagged type that are available (see 13.13.2) at the end of the
declaration list where the type is declared are called dispatching
operations. A dispatching operation can be called using a statically
determined controlling tag, in which case the body to be executed is
determined at compile time. Alternatively, the controlling tag can be
dynamically determined, in which case the call dispatches to a body that is
determined at run time; such a call is termed a dispatching call. As
explained below, the properties of the operands and the context of a particular
call on a dispatching operation determine how the controlling tag is
determined, and hence whether or not the call is a dispatching call. Run-time
polymorphism is achieved when a dispatching operation is called by a
dispatching call.
!ACATS test
An ACATS test should be constructed to test this rule.
!appendix
From: Gary Dismukes
Sent: Wednesday, February 12, 2003 1:12 PM
This is a quick question on stream attributes that arose
from a customer report.
According to my reading of the rules, the stream attributes
as applied to tagged types are not treated as dispatching
operations, since they don't fall into the categorization
of being primitive subprograms by the rules in 3.2.3.
Now the semantics of 'Class'Output are defined to involve
a dispatching call to 'Output. It seems that a user-written
version of 'Class'Output might also want to make dispatching
calls on 'Output, but that's not possible unless 'Output
is a dispatching operation.
So the question is, is it really intended that the 'Output and
'Input subprograms are not dispatching operations, or is there
some reading of the rules that permits dispatching calls to
these attributes?
****************************************************************
From: Tucker Taft
Sent: Wednesday, February 12, 2003 1:40 PM
It seems like we could relatively easily rule either way,
because the manual is not very clear about the intent.
I did check that our compiler allows passing a class-wide
object to T'Output, but does a statically bound call -- probably the
worst of both worlds!
****************************************************************
From: Gary Dismukes
Sent: Wednesday, February 12, 2003 3:12 PM
Interesting, our compiler exhibited that behavior as well :)
It would be useful to find out what some of the other compilers
do with such calls.
Btw, I managed to find one place in the AIs that alluded to the
nondispatching nature of stream attributes, in the famous AI-195
on misc. stream attribute issues. Under issue 5 (relating to
associating a stream attribute with an abstract operation) in the
!discussion section there's a statement:
5 - Obviously it should not be possible to perform a non-dispatching call to
an abstract subprogram (stream-oriented attributes are always called in a
non-dispatching manner). ...
So it looks like at least the person who wrote that (Pascal?) believed
that calls to stream attributes are supposed to be nondispatching.
****************************************************************
Questions? Ask the ACAA Technical Agent