Re: The old "Object.Method" syntax debate

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

Lutz Donnerhacke wrote:

> * Dmitry A. Kazakov wrote:
>> However, overriding attributes raises an interestring question of making
>> everything that could appear on the left side of an attribute a
>> first-class object.
> 
> Furthermore it allows an envolving solution to the original question:
> 
> Drop the restriction which attributes are allowed. Several attributes
> might have a predefined meaning, but other than the predefined attributes
> might be allowed in Ada200x.
> 
> So if you want to apply an 'object.method' syntax, do
> 
>   type object ...;
>   procedure method(a : in out object; ...);
>   for object'method use method;

Or better

object'method renames method;

Now if you do not want to expose method, you would need a sort of private 
renaming:

   object'method renames private;
private
   procedure method(a : in out object; ...);
   object'method renames method;


> But there are more important features missing an Ada 95:
> ************************************************************************
> Newsgroups: comp.lang.ada
> Subject: AdaYY wish list from current projects
> Organization: IKS GmbH Jena
> Message-ID: <96ulad$r9e$1@belenus.iks-jena.de>
> 
> I have three sad problems (and a bonus problem) from my current projects.
> If they can fixed by a compiler it would be very fine:
> 
> Problem 1: Pointer of component => Pointer to aggregate

Solved with MI = Class-wide pointer -> Dispatch

> Problem 2: Defining Byte_Order of record representations

I didn'tunderstand this. Why Value := Low + High * 256 is unsufficient. I 
never had problems in passing integers over sockets. But I admit, I know no 
solution for an efficient dealing with floats (in binary format).

> Problem 3: Static expressions of discriminants in record representations

Yes it is a pain. But the major problem as I see it is breaking separation 
of implementation and interface by discriminants. Clearly there has to be 
public and private (implementational) discriminants. Later deduced from 
former. With true constructors this could be solved.

> Problem 4: Single task packages

My problem is that task and protected types are not tagged and so fall out 
of type hierarchy. Then I would like to have "accept"-procedures (with task 
object as a parameter) in addition to the accept statement.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de