!standard 03.02.03 (06) 05-10-14 AI95-00335/04 !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.] 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 declaration list where the type is declared; 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. 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)". <> !corrigendum 3.2.3(6) @dinsa @xbullet, any subprograms (in addition to the enumeration literals) that are explicitly declared immediately within the same @fa and that operate on the type;> @dinst @xbullet !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. ****************************************************************