Version 1.7 of ais/ai-00335.txt

Unformatted version of ais/ai-00335.txt version 1.7
Other versions for file ais/ai-00335.txt

!standard 03.02.03 (06)          04-11-08 AI95-00335/03
!class binding interpretation 03-07-30
!status Amendment 200Y 04-07-02
!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
Add after 3.2.3(6):
For a specific type, the stream-oriented attributes of the type that are available (see 13.13.2) at the end of the list of declarative_items where the type is declared;
AARM Note: For a type declared immediately within a package_specification which has a partial view, the list of declarative_items to consider is the visible part of the package.
Even if a stream-oriented attribute is specified by an attribute_definition_clause, it is not itself considered a user-defined subprogram, so it is not inherited. Rather, the rules explaining what happens to the stream-oriented attributes on type derivation are spelled out in chapter 13. 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 decide that stream-oriented attributes of specific types are primitive subprograms of the type. This makes them dispatching subprograms in the case of tagged types. Note however that they aren't inheritable in the sense of 3.4(17). They behave more like predefined operators, and are created anew for each type, based on the properties of the type.
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)".
<<Integration Issue: If this AI is adopted, some of the replacement wording for 13.13.2(36/1) in AI-195 should be changed to read "the corresponding attribute of T is a primitive subprogram of T". This would avoid a bit of wording replication.>>
!corrigendum 3.2.3(6)
Insert after the paragraph:
the new paragraph:
!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