CVS difference for ais/ai-00252.txt

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

--- ais/ai-00252.txt	2003/06/28 00:41:07	1.5
+++ ais/ai-00252.txt	2003/07/26 03:26:01	1.6
@@ -4,7 +4,7 @@
 !status received 00-12-04
 !priority High
 !difficulty Hard
-!subject Object.Operation Notation
+!subject Object.Operation notation
 
 !summary
 
@@ -424,5 +424,254 @@
 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).
+
+****************************************************************
+
+From: Alexander Kopilovitch
+Sent: Monday, June  9, 2003 10:09 AM
+
+!summary
+
+An alternative syntax is proposed here for AI-252. This alternative uses
+new attribute instead of extension for meaning of dot-qualification, which is
+currently proposed in AI-252. This text assumes the context of current AI-252.
+
+!proposal
+
+Let us introduce new attribute Method, which always must be followed by dot
+and operation, i.e.
+
+  Object'Method.Operation
+
+for example:
+
+  type T is ... ;
+  function F(A1 : T; A2 : Integer) return Integer;
+  procedure P(A1: T);
+  ...
+
+  X : T;
+  Actual_A2 : Integer;
+  F_Result : Integer;
+  ...
+
+  F_Result := X'Method.F(Actual_A2);
+  ...
+  X'Method.P;
+
+Conceptually, the attribute Method returns a record -- the table of all
+relevant methods; some analogy with C++ code is present here, although the
+major difference is obvious: contents of this table depends not only on the
+object's type, but on surround and visibility rules also.
+
+Basic visibility rules for Operation may stay as they are stated currently
+in AI-252, but with additional option: a programmer can explicitly list all
+visible packages for a particular subtype using appropriate "for...use"
+statement:
+
+  for Subtype'Method use Package1 [, Package2, ..., PackageN];
+
+Such explicit statement overrides basic visibility rules for all
+Object'Method.Operation expressions where Object belongs to Subtype.
+
+Further, with this approach we may easily provide a denotation for the
+component-on-demand abstraction, that is, unified notation for an externally
+immutable view of a data component and a function; all we need for this is
+another attribute Property, which should be used the same way:
+
+  Object'Property.Function_Or_DataField
+
+for example, for both
+
+  type T is ... ;
+  function F(P : T) return Integer;
+
+and
+
+  type T is record
+     F : Integer;
+     ...
+  end record;
+
+we can write:
+
+  X : T;
+  R : Integer;
+  ...
+
+  R := X'Property.F;
+
+Arguments for a function prefixed by the Property attribute naturally
+correspond indices for array data component.
+
+Further, arrays (that are indexed by controlling object type) likewise may be
+used in conjunction with the Property attribute  (in accordance with analogy
+between arrays and functions, supported in Ada). For example:
+
+  type String_Index is new Integer;
+  S : String(1..10);
+  I : String_Index;
+  ...
+  ... I'Property.S ...
+
+Even multi-dimensional arrays are permitted here. For example:
+
+  type Cities is (Edinburgh, Glasgow, London, Paris, New_York);
+  type Distances is array (Cities, Cities) of Float;
+  Km_To : Distances := ...;
+  ...
+  ... Edinburgh'Property.Km_To(Paris) ...
+
+As for arrays of arrays, only outer array may be used, that is, the subscripts
+for inner arrays cannot appear. For example:
+
+  type Table_Index is new Integer;
+  type Table_Line is String(1..50);
+  Table : array (Table_Index range 1..10) of Table_Line;
+  I : Table_Index;
+  ...
+  ... I'Property.Table ...     -- legal
+  ...
+  ... I'Property.Table(1) ...  -- illegal
+
+
+!discussion
+
+Object.Operation syntax seems as acceptable compromise in a case when
+there is a controlling object. Although even then the Operation does not
+belong to the Object (as it belongs to a package), it is reasonable to claim
+that conceptually, the status of being controlling temporary gives the Object
+some additional rights over all its operations, and in particular, extends
+visibility rules for the Object.
+
+But in many cases there are no controlling objects, and in those cases this
+Object.Operation syntax will act against proper expression and understanding
+of program design and logic. Moverover, as this Object.Operation style
+potentially conflicts with package-orientation, which is fundamental feature
+of Ada 95, and as this Object.Operation notation is compulsory in most of
+today's mainstream languages, there is real possibility of massive and
+disordered mixture of those design styles if this Object.Operation notation
+appear in Ada.
+
+There is also anxiety about possible confusion with component notation.
+As Robert I. Eachus recently wrote in comp.lang.ada newsgroup
+(message-id <3ED056CB.8000200@attbi.com> ):
+"I really don't like the idea of allowing the Object.Operation format to
+Ada.  Yeah, the compilers can usually figure it out understand it. But
+the potential confusion with component notation is going to confuse
+experienced Ada users.  (And eventually other O-O language users when
+the actually run into component references."
+
+An alternative proposed here attains main purpose of AI-252, and it does not
+contest AI's propositions concerning all things except Object.Operation
+syntax. At the same time it establishes a deterrent for unjustified use of
+the feature (by extra wording), makes the expression of programmer's intent
+more explicit, and additionally, provides finer control over visibility and
+over interchangeability between operation and data field.
+
+The level of uniformity achieved with the notation proposed here is even
+higher than with dot-notation proposed in current AI-252 (because the arrays
+are included) without sacrificing traditional features and natural ways for
+expressing specific intentions.
+
+****************************************************************
+
+From: Craig Carey
+Sent: Wednesday, June 11, 2003  3:47 AM
+
+The AI-00252 maybe does not go far enough: it is not about putting ","s
+after types.
+
+Here is an example that would occur when creating Ada bindings to C++
+*.h files. Two unsatisfactory details are that "Cpp.A.A" & "Cpp.A.Value"
+are to be used instead of "A.A" and "A.Value".
+
+package Cpp is
+
+   package A is
+      type A_Rec is tagged limited null record;
+      subtype A is A_Rec'Class;
+      function Value return A;
+   end A;
+
+   package B is
+      subtype A is Cpp.A.A;
+      procedure F (T : A := A.Value);  -- Not legal, the
+                        --  A in "A.Value" is a subtype
+   end B;
+
+end Cpp;
+
+If the "subtype A is Cpp.A.A;" is replaced with "use A;" then
+the error shifts to the "A" in the "A :=", with the problem now
+being that it can't see the type but thinks that that A is a
+package.
+
+If both "subtype A is Cpp.A.A;" and "use A;" are used, then the
+error returns back to the "A.Value" with the ObjectAda compiler
+saying that the "A" in "A.Value" is the type "A" and not the
+package "A".
+
+The language could be improved to better resolve overlaps of
+subtype names and package names. (Maybe AI-00252 could consider
+this (it might eventually consider dots after tokens naming
+subtypes)).
+
+
+At 2003\06\09 19:09 +0400 Monday, Alexandre E. Kopilovitch wrote:
+>!summary
+>
+...
+
+That proposal suggested two keywords ("Method", and "Property").
+That is general and there I doubt arguments for that would show
+up. AI-00252 said 0 special tokens and a "'" is best.
+
+****************************************************************
+
+From: Craig Carey
+Sent: Wednesday, June 11, 2003  8:07 AM
+
+Ada could have a 'class' feature. It can be implemented in that way,
+for example:
+
+------------------------------------------------------------
+package Cpp is
+   type Y is tagged limited null record;
+
+   package A is      -- The "<>" means that this is a class
+      type A_Rec is new Y with   -- (or "is tagged")
+         record
+            N : Integer;
+         end record;
+
+      subtype <> is A_Rec'Class;         --  Glue this subtype into whole package
+      type A_Ptr is access constant A;   --  this "A" is the "<>" type
+
+      Static  : aliased A_Rec;
+      function Value return A;
+   end A;
+
+   Var   : A.A_Ptr := A.Static'Access;
+
+   package B is
+      procedure F (T : A := A.Value);  -- Legal now
+   end B;
+
+end Cpp;
+------------------------------------------------------------
+
+In general, statements like this:
+
+   subtype X is X.Y;
+
+just spill out the contents of record Y into the larger surrounding
+X record.
+The word "renames" is an alternative to "subtype".
+
+By this means, abstract multiple inheritance could be implemented without
+a use of the tagged type. Instead of dispatching when procedures are
+called, the programmer explicitly specifies the subrecord by gluing on
+extra text after a dot.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent