Re: Ada Annoyances

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 17-06-27 00:47 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:erd8jiFhsroU1@mid.individual.net...
>> On 17-06-26 02:43 , Randy Brukardt wrote:
> ...
>>>> Point (b) is more difficult and I know of no work-around that can be
>>>> applied at analysis time.
>>>
>>> Simply banning the use of T'Class has that effect.
>>
>> At design and compilation time, yes, with consequent restrictions on the
>> design. But it is not a work-around that allows static analysis of
>> programs which do use T'Class.
>
> There's no free lunch! T'Class is by definition "indefinite", since existing
> code already compiled has to be able to handle newly defined types
> (including those that don't yet exist). That's never going to allow
> conventional static analysis.

As already appeared in other posts, the aim of the proposed Maximum_Size 
aspect is to make this T'Class type behave as a definite type. The rules 
for Maximum_Size would have to be defined in such a way that a change of 
the Maximum_Size value would force recompilation of any code depending 
on the value.

>> My hope is that a Maximum_Size aspect would let one manipulate class-wide
>> objects in the same "definite" way as is possible for variant records with
>> a default discriminant value. However, it would require that the tag of an
>> object could be changed by assignment; this is perhaps too radical a
>> change in the tagged object semantics.
>
> That seems way too drastic a change.

There is a parallel with the ability or inability to change the 
discriminants of a record-type object, which depends on the presence of 
default values for the discriminant, that is, on whether the object is 
unconstrained or constrained.

> I could imagine an aspect like the one
> you proposed to get rid of the indirection, but changing the semantics in a
> major way seems to be more than aspects are supposed to do.

I understand. However, I think I will write up the suggestion for 
ada-comment, to get it on the record.

> And changing the tag via assignment means having to be prepared to
> change finalization of  objects after the fact as well. Ugh.

Isn't finalization of local objects usually implemented by creating a 
list of these objects, and then traversing that list on scope exit? It 
seems to me that changing the tag of an object on the list should not be 
a problem; the new tag would just lead to a different Finalize, through 
normal dispatching.

But perhaps there are other implementations where the particular 
Finalize operation for a local object is determined when the 
local-object declaration is elaborated, and therefore corresponds to the 
initial tag value?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .