CVS difference for ais/ai-00252.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00252.txt

--- ais/ai-00252.txt	2000/12/07 03:49:45	1.2
+++ ais/ai-00252.txt	2001/10/09 00:47:09	1.3
@@ -1,10 +1,10 @@
-!standard 04.01.03 (05)                               00-12-04  AI95-00252/01
+!standard 04.01.03 (05)                               01-10-05  AI95-00252/02
 !class amendment 00-12-04
 !status work item 00-12-04
 !status received 00-12-04
 !priority High
 !difficulty Hard
-!subject Tagged Types, Object.Operation Notation, Object-Oriented Programming
+!subject Object.Operation Notation
 
 !summary
 
@@ -41,14 +41,44 @@
 produced, because the operations made visible would all overload one another,
 rather than having operations from one package hide another.
 
+To allow operations that are declared in the current package body to be
+visible, the directly visible declarations are considered prior to the
+(implicitly) use-visible declarations. As usual, the directly visible
+operations can hide the use-visible declarations, but the use-visible
+declarations cannot hide each other (they only overload each other).
+
 Because of access parameters, if the type of the prefix is an access type, the
-package(s) in which the designated type and types that cover the
-designated type would be "use"d, in addition to the package in which the
-access type itself is declared. Furthermore, to preserve the model that "."
-can result in an implicit dereference, an interpretation of the prefix as
-an implicit dereference is coupled with a "use" of the packages in which the
-designated type and its coverings are declared. In this implicit dereference
-case, the package where the access type itself is declared is irrelevant.
+package(s) in which the designated type and types that cover the designated
+type would be "use"d, in addition to the package in which the access type
+itself is declared. Furthermore, to preserve the model that "." can result in
+an implicit dereference, an interpretation of the prefix as an implicit
+dereference is coupled with a "use" of the packages in which the designated
+type and its coverings are declared. In this implicit dereference case, the
+package where the access type itself is declared is irrelevant.
+
+As a final potentially useful addition, if the object is aliased,
+interpretations where 'Access would be needed after the object name are
+considered.  That is, even if the prefix is not of an access type, operations
+with the first parameter being an access parameter designating the type of the
+prefix are considered. This would mean that access parameters can be used in
+general in primitives, without penalizing the person who actually declares an
+(aliased) object on the stack rather than using the heap.
+
+One way of describing what is happening is that operations declared in the
+package immediately enclosing a type declaration that have the type (or
+"access" type or covering-type'Class) as their first parameter, are implicitly
+declared as components of a type, but with the first parameter removed. These
+implicitly declared components are then inherited when the type is extended.
+Use-visibility rules are used for these implicitly-declared components to avoid
+"beaujolais" effects.
+
+Note that if the prefix type is not tagged and not access, this only makes
+available primitive operations in the package where the type is declared.  If
+the type is tagged, it makes the classwide operations from the packages where
+"coverings" are declared, plus the primitives from the package where the type
+itself is declared. If the type is an access type, it makes primitives
+available from the package where the access type is declared, plus operations
+that would have been made available for the designated type.
 
 !discussion
 
@@ -81,18 +111,29 @@
 of course it is relevant to how it is handled in type extensions). The
 "package"-oriented approach, as opposed to the "primitive"-oriented approach,
 may also fit more cleanly into existing overload resolution algorithms, since
-it has more in common with the way "use" visibility works currently.
-Of course, any guess of implementation burden is hard to make, since compilers
-have so many different strategies.
+it has more in common with the way "use" visibility works currently. Of course,
+any guess of implementation burden is hard to make, since compilers have so
+many different strategies.
 
 The rules for access types are a bit convoluted, but they seem necessary given
-the importance of access parameters.
+the importance of access parameters. Adding the implicit "'Access" seems like
+a useful capability, without significantly complicating the proposal.
 
 We talk about "covering" types rather than "ancestor" types for two reasons.
 One is that it is only operations on class-wide types that are being imported
 from packages other than the one in which the type itself is declared. Second,
 the notion of "covers" will presumably generalize better if we adopt the notion
 of abstract interfaces (see the multiple inheritance Amendment AI).
+
+Note that operations on class-wide types can be used even if the package in
+which they are declared is not "with"ed. This is part of the whole point. A
+class-wide operation may be introduced anywhere in the type hierarchy, and it
+will be available via the object.operation(...) notation without having to
+identify the specific package. Since only packages where the "coverings" of
+the type are declared are considered, this "implicit with" is not actually
+creating any new semantic dependences. Essentially it is as though these
+class-wide operations are being inherited, but with no possibility of
+overriding. They are like "final" operations in Java.
 
 !example
 

Questions? Ask the ACAA Technical Agent