Re: The old "Object.Method" syntax debate

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

Lutz Donnerhacke wrote:

> * Dmitry A. Kazakov wrote:
>> Lutz Donnerhacke wrote:
>>>   procedure method(a : in out object; ...);
>>>   for object'method use method;
>> 
>> Or better
>> 
>> object'method renames method;
> 
> I do not like to introduce just another syntax for attribute definitions.
> 
>>> Problem 1: Pointer of component => Pointer to aggregate
>> 
>> Solved with MI = Class-wide pointer -> Dispatch
> 
> I do not have tagged data types. Due to hardware design requirements I can
> not have tagged data types.

It is a strange view. In my present embedded project I am widely using 
tagged types (it is not a 16-bit controller, though). I do not think that 
any kludge I might invent would outperform the compiler generated code.

>>> 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).
> 
> A portable program using record representation clauses is not possible to
> write in Ada95 (besides you restrict yourself to boolean components only).
> If you like to show me something other, please consider a 6bit bytesize
> and 36bit wordsize processor ...
> 
> The portable solution for complex data types is writing distinct parsing
> and constructing routines. This is inefficient and can not applied to
> memory mapped data. I do not accept this limitation of Ada95.

It seems that you consider Ada <-> Ada communication, which is a minor case. 
My problem is Ada <-> Something communication. It is a delusion to hope 
that any sort of representation clause might exclude parsing (do not forget 
protocal error detection). Did you see proprietary CAN-bus protocols? You 
would need rather Freud than Ada to deal with that! (:-))

>>> 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.
> 
> I do not see any seperation by declarative programming.
> 
>> Clearly there has to be public and private (implementational)
>> discriminants.
> 
> No. An external (memory mapped) data structure has only public components.
> Representation issues does no deal with private and public differences
> either.

I suppose you will first copy an object from the dual-ported RAM to 
conventinal RAM before dealing with the data. Those objects better have 
different representation.

>> With true constructors this could be solved.
> 
> Initialisation routines exists and do not solve the problem. Constructor
> routines do not solve the memory mapping either. So what?

If I can construct in-place, I am free to chose a type representation at 
will (a bit array if things are really bad). The price is a slover data 
access, of course.

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