Re: In-Out Parameters for functions + object notation

["Alexandre E. Kopilovitch" <aek@VB1162.spb.edu>]

Dmitry A. Kazakov wrote:

> I am afraid that allowing IN OUT parameters would be inconsistent with
> the functions of the protected objects. Provided that the prefix
> notation creeps Ada, it will be difficult to explain when X.Foo may
> change X and when not.

I think that with the following alternative proposal for prefix notation
(which I have sent to Ada-Comment in June 2003) all that would be clearer:

-------------------------------------------------------------------------

!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.

________________________________________________________



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia