CVS difference for ais/ai-00108.txt

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

--- ais/ai-00108.txt	2000/06/20 04:22:42	1.9
+++ ais/ai-00108.txt	2000/06/21 23:39:08	1.10
@@ -33,16 +33,16 @@
 
 13.1(15) says:
 
-15   A derived type inherits each type-related aspect of its parent type that
-was directly specified before the declaration of the derived type, or (in the
-case where the parent is derived) that was inherited by the parent type from
-the grandparent type.  A derived subtype inherits each subtype-specific
-aspect of its parent subtype that was directly specified before the
-declaration of the derived type, or (in the case where the parent is derived)
-that was inherited by the parent subtype from the grandparent subtype, but
-only if the parent subtype statically matches the first subtype of the parent
-type.  An inherited aspect of representation is overridden by a subsequent
-representation item that specifies the same aspect of the type or subtype.
+  A derived type inherits each type-related aspect of its parent type that
+  was directly specified before the declaration of the derived type, or (in the
+  case where the parent is derived) that was inherited by the parent type from
+  the grandparent type.  A derived subtype inherits each subtype-specific
+  aspect of its parent subtype that was directly specified before the
+  declaration of the derived type, or (in the case where the parent is derived)
+  that was inherited by the parent subtype from the grandparent subtype, but
+  only if the parent subtype statically matches the first subtype of the parent
+  type.  An inherited aspect of representation is overridden by a subsequent
+  representation item that specifies the same aspect of the type or subtype.
 
 Do these rules apply to the stream-oriented attributes Read, Write,
 Input, and Output?  (No.)
@@ -106,13 +106,17 @@
 We must take care, however, that all of the components have the appropriate
 attributes. For a limited type extension, the extension component could be
 of a type that does not have an implementation of Write or Read. In that
-case, we must take care to insure that the attribute for the new type cannot
-be called, either. (A alternative would be to inherit the original
-operation unmodified, but this would silently ignore the extension components.
-This could cause hard-to-find bugs as the components would probably revert to
-default values when they are input. This is similar to the way that
-functions of type extensions are inherited: they aren't inherited, they
-must be overridden.
+case, we must take care to insure that the attribute for the new type does
+handle the extension component. We do this by requiring an attribute
+to be directly specified if it has a limited extension component that does
+not have an implementation of Write or Read and the parent type does have a
+(specified) implementation of Write or Read. (A alternative would be to inherit
+the original operation unmodified, but this would silently ignore the extension
+components. This could cause hard-to-find bugs as the components would probably
+revert to default values when they are input.) This rule is similar to the way
+that functions of type extensions are inherited: they aren't inherited, they
+must be overridden (except that we only invoke it when we can't do the right
+thing automatically).
 
 Clearly, the properties of the default implementation for the stream
 attributes can change for derived types (as in the example given in
@@ -120,19 +124,20 @@
 implementation for an attribute, rather than inheriting a default
 implementation from the parent type.
 
-For language defined nonlimited private types, the RM does not say
-whether the stream-oriented attributes must work properly.  It seems
-that they ought to.  For many such types, the default version will work
-properly.  However, for a type like Unbounded_String, which is almost
+For language defined nonlimited private types, the International Standard
+does not say whether the stream-oriented attributes must work properly.
+It seems that they ought to. For many such types, the default version will work
+properly. However, for a type like Unbounded_String, which is almost
 certainly implemented as a data structure involving pointers, the
-default versions will not work.  Therefore, for these types, the
+default versions will not work. Therefore, for these types, the
 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.
+(see DR-0009 [AI-00137]) to say that whether operational attributes are
+inherited depends on the attribute. This simplifies the wording by
+eliminating the need to describe a long list of exceptions to an inheritance
+rule that we want only in some cases, and provides future flexibility.
 
 !corrigendum 13.1(15)
 
@@ -1363,7 +1368,11 @@
 
 This is bit different than Tucker's suggestion, mainly so that there is no
 requirement to specify an attribute if the parent attribute wasn't specified.
-I also used "specified" (in the sense of 13.1(18/1) - the paragraph Tucker would like to get rid of) rather than "callable" - which would require a definition. This gets a bit messy because limited type extension's attributes can be callable without being
 "specified" (inherited or directly specified); but in that case, some ancestor type must have been directly specified.
+I also used "specified" (in the sense of 13.1(18/1) - the paragraph Tucker would
+like to get rid of) rather than "callable" - which would require a definition.
+This gets a bit messy because limited type extension's attributes can be
+callable without being "specified" (inherited or directly specified); but in
+that case, some ancestor type must have been directly specified.
 
 
 > Furthermore, I would suggest that Output and Input piggy back automatically
@@ -1381,5 +1390,15 @@
 these always use the default implementation, but leaves them uncallable for
 limited types). But I'm not sure it is useful for the implementation burden --
 Input is a function after all, and limited functions aren't very useful.
+
+****************************************************************
+
+Editor's note to himself:
+
+After the Potsdam meeting, (if this has been approved):
+
+-- Remove points 3 and 5 from AI-00195;
+-- Add Tucker's suggestion above to AI-00195;
+-- Renumber AI-00195's questions?
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent