Re: Syntax for tagged record types and class types

[Mats Weber <Mats.Weber@elca-matrix.ch>]

Matthew Heaney wrote:

> I'm not dogmatic about the "pure" object-oriented syntax, ie
> 
> declare
>    O : T;
> begin
>    O.Op (A);
> end;
> 
> though I do think it's pretty hip.

So do I. And if tasks and protected types provide that kind of notation,
why should this not also be true for other constructs ?

> What would be cool is to have a selector abstraction, to give you that for
> free, ie
> 
> type Stack is ...;
> 
> selector Top (S : Stack) return Item;
> 
> So that I could do this:
> 
> declare
>    The_Stack : Stack;
> begin
>    The_Item := The_Stack.Top;
> ...

That's why I proposed to use package types in my thesis (at
<http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html>).
You example would be written

package type Stack is

   function Top return Item;

   procedure Push (X : in Item);

   ...

private

   ...

end Stack;

(just like a task or protected type). Of course there are a few
restrictions on what you can put into a package type, for instance you
can't declare a type within a package type.

I chose the package type syntax because of similarities with task types,
but there is absolutely no problem in changing the syntax to something
different (for those allergic to package types :-), e.g.

class type Stack is ...   -- new keyword for OO types

type Stack is
   record                           -- allow subprograms in records
      function Top return Item;
      procedure Push (X : in Item);
      ...
   end record;

All three approaches are essentially equivalent. I chose package types
because packages already have a private part, which is very useful, and
because I make some further use of the task-package similarity that is
very useful for expressing abstract data types that are needed in both
concurrent and non-concurrent variants (e.g. Booch components).

>[...]

> It's always bothered me a bit (and Bertrand Meyer, too; read his book) that
> the syntax for selecting an unencapsulated (public) component has to be
> different from selecting an encapsulated one.
> 
> The_Stack.Top vs. Top (The_Stack)
> 
> Especially since we've sort of made this statement that tagged types are
> "really" records, it would be cool to take the analogy a step farther, by
> making component selection uniform.

Absolutely.

> While we're at it, maybe we can throw in real constructors, too.  We can
> solve the "problem" with limited types,  by allowing a constructor to be
> called in the declarative region.  That way limited types wouldn't have to
> be definate, or go on the heap unnecessarily.

My proposal for constructors goes like this:

package type T is
   procedure new (X : Integer; Y : Float);   -- Note: new is a keyword
   ...
end T;

...

Object : T(X => 5, Y => 3.14);

the elaboration of the object declaration creates the object and then
calls the procedure new with the given parameters. This is very useful
in many situations and does not have the limitations that are enforced
on discriminants, and you can have several overloaded versions of the
new procedure, wheareas discrimiants force you to have a fixed
initialization formal part.

Details of these proposed constructs can be found at the above URL.

Class types provided this way (any of the above 3 syntax) do not specify
the mode of the implicit parameter of the class type. This has the nice
side effect that a function can modify the object on which it is
applied, which would be very useful in cases like the random number
generator discussed in another thread.