CVS difference for ai05s/ai05-0080-1.txt
--- ai05s/ai05-0080-1.txt 2008/01/17 07:24:41 1.1
+++ ai05s/ai05-0080-1.txt 2008/03/07 06:15:19 1.2
@@ -1,5 +1,6 @@
-!standard 3.1(7) 08-01-16 AI05-0080-1/01
+!standard 3.1(7) 08-02-22 AI05-0080-1/02
!class binding interpretation 08-01-16
+!status ARG Approved 7-0-1 08-02-10
!status work item 08-01-16
!status received 07-12-07
@@ -16,7 +17,7 @@
We often have arguments about whether "object" or "type" means exactly that,
or whether it really means "view of an object" or "view of a type". It's
-generally agreed that the Standard would make any sense if this is not
+generally agreed that the Standard would not make any sense if this is not
applied, because there are many places where a view is what is being considered
(otherwise privacy would be broken).
@@ -30,23 +31,24 @@
Add after 3.1(7):
When it is clear from context, the term *object* is used in place of *view
-of an object*. Similarly, the term *type" is used in place of "view of a type".
+of an object*. Similarly, the terms *type* and *subtype* are used in place
+of *view of a type* and *view of a subtype*, respectively.
- Rules interpreted at compile-time generally refer to views of entities,
+ Rules interpreted at compile time generally refer to views of entities,
rather than the entities themselves. This is necessary to preserve privacy;
characteristics that are not visible should not be used in compile-time
rules. Thus, Static Semantics and Legality Rules generally implicitly have
- "view of". Legality Rules that need to ignore the private part (for instance,
- those involving representation items) are the exception to this interpretation.
+ "view of". Legality Rules that need to look into the private part
+ are the exception to this interpretation.
On the other hand, run-time rules can work either way, so "view of" should
not be assumed in Dynamic Semantics rules.
@@ -58,14 +60,37 @@
as many bugs as it would fix. So we go with a blanket statement.
We have to be careful with the wording, because it is not quite all of the time
-(even at compile-time) that "view of" should be assumed. It is especially hard
+(even at compile time) that "view of" should be assumed. It is especially hard
to "unassume" it when it is inappropriate. Thus the wording is intentionally vague.
-Note that this wording implies that "view of" should not be assumed in dynamic
-rules; any that need "view of" and do not have it are wrong.
+It should be noted that we were not able to come up with an example of a compile
+time rule that should not assume "view of". In particular, the example of
+representation items for types was suggested, but since those have to be the same
+for all views, there is no difference between using a view of the type and using
+the type itself. In addition, there are a few rules written in terms of the
+full type, which clearly is specifying which view to use. On the other hand,
+given the sheer size of the Ada Standard, it would be foolhardy to assume that
+there is no such case anywhere, and this is a non-critical fix, so we don't want
+it to unintentionally break the standard somewhere else.
+Note that the intent (as reflected by the AARM Note) is that "view of" should not
+be assumed in dynamic rules; any that need "view of" and do not have it are wrong.
+All declarations contain a @i<definition> for a @i<view> of an entity. A view
+consists of an identification of the entity (the entity @i<of> the view), plus
+view-specific characteristics that affect the use of the entity through that view
+(such as mode of access to an object, formal parameter names and defaults for
+a subprogram, or visibility to components of a type). In most cases, a declaration
+also contains the definition for the entity itself (a renaming_declaration is
+an example of a declaration that does not define a new entity, but instead
+defines a view of an existing entity (see 8.5)).
+When it is clear from context, the term @i<object> is used in place of @i<view
+of an object>. Similarly, the terms @i<type> and @i<subtype> are used in place of
+@i<view of a type> and @i<view of a subtype>, respectively.
Questions? Ask the ACAA Technical Agent