CVS difference for ais/ai-00108.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00108.txt

--- ais/ai-00108.txt	2000/03/09 03:09:40	1.5
+++ ais/ai-00108.txt	2000/04/14 01:45:07	1.6
@@ -99,6 +99,11 @@
 implementer must provide an explicit version of the Read and Write
 attributes.
 
+The wording takes advantage of the newly defined "operational attributes"
+(see AI-00137) to say that operational attributes are never inherited.
+This simplifies the wording by eliminating the need to describe a long
+list of exceptions to an inheritance rule that we don't actually want.
+
 !corrigendum 13.1(15)
 
 @drepl
@@ -151,19 +156,36 @@
 For nonlimited type extensions, the Write or Read attribute for the parent type
 is called, followed by the Write or Read attribute of each non-inherited
 component, in canonical order. For other derived types, the Write or Read
-attribute of the parent type is inherited.
+attribute of the parent type is called.
+
+!corrigendum 13.13.02(26)
+
+@drepl
+@xbullet<If @i<T> is an array type, S'Output first writes the bounds, and
+S'Input first reads the bounds.  If @i<T> has discriminants without defaults,
+S'Output first writes the discriminants (using S'Write for each), and S'Input
+first reads the discriminants (using S'Read for each).>
+@dby
+@xbullet<If @i<T> is an untagged derived type, the Output or Input attribute
+of the parent type is called, if one exists.>
+@xbullet<For other types:>
+@xinbull<If @i<T> is an array type, S'Output first writes the bounds, and
+S'Input first reads the bounds.  If @i<T> has discriminants without defaults,
+S'Output first writes the discriminants (using S'Write for each), and S'Input
+first reads the discriminants (using S'Read for each).>
 
 !corrigendum 13.13.02(27)
 
-@dinsa
-@xbullet<S'Output then calls S'Write to write the value of @i<Item> to the
+@drepl
+@xbullet<S'Output then calls S'Write to write the value of Item to the
 stream. S'Input then creates an object (with the bounds or
 discriminants, if any, taken from the stream), initializes it
 with S'Read, and returns the value of the object.>
-@dinst
-If @i<T> is a type extension, S'Output and S'Input are not inherited from the
-parent type; they are defined in terms of S'Read and S'Write, notwithstanding
-the inheritance rule stated in 13.1.
+@dby
+@xinbull<S'Output then calls S'Write to write the value of Item to the
+stream. S'Input then creates an object (with the bounds or
+discriminants, if any, taken from the stream), initializes it
+with S'Read, and returns the value of the object.>
 
 !corrigendum 13.13.02(36)
 
@@ -285,5 +307,143 @@
 
 Paragraph 13.1(15.1) is not normative (it follows from other rules), and
 could be omitted.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, April 12, 2000 9:57 PM
+
+While doing the (almost) final check on the Corrigendum, I noticed the
+following:
+
+The new paragraph 13.13.2(27.1) says:
+
+If T is a type extension, S'Output and S'Input are not inherited from the
+parent type; they are defined in terms of S'Read and S'Write,
+notwithstanding the inheritance rule stated in 13.1.
+
+But the rewritten 13.1(15) says that operational attributes are never
+inherited. It seems to me that this entire change can be deleted. (This is
+AI-00108).
+
+Additionally, the last sentence of the new 13.13.2(9) says:
+
+       For other derived types, the Write or Read attribute of the parent
+type is inherited.
+
+Again, 13.1(15) says that operation attributes are never inherited. I think
+it would be better to say that the parent attribute is "called", which would
+be similar to the way that the implementation for type extensions are
+described.
+
+Any comments??
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, April 13, 2000 11:09 AM
+
+I am surprised that we say that operational attributes are never
+inherited.  It seems like this needs to be a per-attribute
+decision.  Inheriting something like external_tag does seem unwise,
+but inheriting 'Read from a parent non-tagged type makes perfect
+sense.
+
+Perhaps we could say that operational attributes are
+never inherited for tagged types, though their actions may be
+incorporated as part of the default implementation for the
+type extension.  However, that doesn't work for 'Read/'Write for
+limited tagged types, where they won't have any attribute
+at all if it isn't inherited.  The operational attribute
+writeup needs some revision perhaps.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, April 13, 2000 7:14 PM
+
+Tucker said:
+
+> I am surprised that we say that operational attributes are never
+> inherited.  It seems like this needs to be a per-attribute
+> decision.  Inheriting something like external_tag does seem unwise,
+> but inheriting 'Read from a parent non-tagged type makes perfect
+> sense.
+
+I looked this up to see why Pascal made it this way, and discovered that I had
+talked him into this change at the last minute. Oh well, I'll have to go it
+alone.
+
+First of all, it is important to remember that operational item are a class of
+attributes that certainly can be extended by both implementation-defined ones
+and possibly by future amendments to the standard. Rules motivated solely by the
+behavior of the current members of the class are best avoided. (That is, after
+all, how we got into this mess in the first place.) So I immediately reject any
+wording that handles non-tagged types differently than tagged types in the
+definition of operational items (i.e. in 13.1(15)).
+
+I'm also concerned about defining a heavy, complex inheritance mechanism, then
+saying that it doesn't apply in most existing cases. I have a note saying that
+the current 13.1(15.1/1) is in fact non-normative: because it says there is
+nothing special happening. This certainly is the cleanest solution.
+
+Finally, the current wording (the predefined value of each aspect is used) in
+fact defers the decision as to whether or not to inherit to each attribute. That
+was the intent, and is what Tucker says he wants.
+
+> Perhaps we could say that operational attributes are
+> never inherited for tagged types, though their actions may be
+> incorporated as part of the default implementation for the
+> type extension.  However, that doesn't work for 'Read/'Write for
+> limited tagged types, where they won't have any attribute
+> at all if it isn't inherited.  The operational attribute
+> write-up needs some revision perhaps.
+
+AI-00108 makes it pretty clear that 'Read and 'Write are *never* inherited for
+tagged types, rather they are composed. If that is the case, then it is seems
+very dangerous for there to be any inherited or predefined 'Read/'Write for a
+limited tagged type: there may be limited components in the extension that don't
+have a 'Read or 'Write to call. To say that limited tagged types are not
+composed (the only alternative) would be inconsistent and confusing.
+
+The wording for 13.13.2(9) says "For other derived types, the Write or Read
+attribute of the parent type is called."  (Or "inherited" instead of "called").
+The intent is that here we are defining the predefined meaning for a derived
+type to inherit the meaning of the parent type.
+
+This wording seems too vague to me, since it isn't clear whether derived
+elementary types are included or not. (You have to read the entire paragraph to
+see the problem.) I think it ought to say something more like: "For non-tagged
+derived types, the Write or Read attribute of the parent type is called, if one
+exists."
+
+After I wrote all of the above, I noticed that inheritance of limited 'Read,
+etc. is moot. 13.13.2(36) says "An attribute_reference is illegal if the type is
+limited, unless the attribute has been specified by an
+attribute_definition_clause". Clearly, any "inherited" or even "predefined"
+attribute for a derived limited has not been specified by an
+attribute_definition_clause (which is a syntactic entity). Thus, while such an
+attribute might exist, it is always illegal to call it. Certainly, the proposed
+changes have no effect on that property.
+
+So, my conclusion is that the Corrigendum wording is correct for 'Read and
+'Write.
+
+There does seem to be a problem for 'Input and 'Output for untagged derived
+types: the current wording reverts them to their predefined implementation,
+rather than inheriting them. That would be an gratuitous change, not supported
+by AI-00108.
+
+I propose to repair this problem by adding the following in front of 13.13.2(26)
+(and indenting (26-27) further):
+
+o If T is an untagged derived type, the Output or Input attribute
+  of the parent type is called, if one exists.
+o For other types:
+
+
+I believe this takes care of the open problem with inheritance.
+
+Now, I'll don my fireproof suit. :-)
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent