Re: Type invariants and private extensions?

[Victor Porton <porton@narod.ru>]

Shark8 wrote:

> On Tuesday, September 12, 2017 at 2:09:08 PM UTC-6, Victor Porton wrote:
>> Jeffrey R. Carter wrote:
>> 
>> > 
>> > "I want to" is not the same as "there is no way to solve the problem in
>> > current Ada". Ada has a feature that provides exactly what you need.
>> > It's called a variant record.
>> 
>> It is a tagged type. AFAIK, a type cannot be both a variant record and
>> tagged.
> 
> You certainly can:
> 
>     Type Type_Enumeration is ( TInteger, TReal, TBoolean, Nothing );
>     
>     Type Example( Item_Type : Type_Enumeration ) is tagged record
> case Item_Type is
> when TInteger => I : Integer;
> when TReal    => R : Float range Float'Range;
> when TBoolean => B : Boolean;
> when Nothing  => Null;
> end case;
>     end record;
>     
>> Moreover, the object in consideration is a wrapper over a certain C API.
>> It surely cannot be described in variant record terms.
> 
> Sure it can; there's a reason that there's a separation between
> specification and body, part of which is so you can hide something like an
> interface to C and present something sensible to your program/clients.

Thanks.

But this seems not to solve my problem:

The base type for Example cannot be defined as a discriminated type for 
certain Type_Enumeration, because it is possible that when creating the 
object it may be yet unknown what the value of the discriminant should have 
(my main problem is to invent somethings if this value is known at object 
creation, but we must support the unknown case too). AFAIK, it is not 
possible to change the discriminant later.

The solution would be to define a discriminated type as its descendant, but 
then all problems which I described in previous messages appear again. So 
this is not a solution.

Hm, we can make Type_Enumeration to contain the value "Any" to allow any 
result type. This is formally a solution, but it is against OO principles 
such as the principle that derived types should be made by object 
inheritance. Wait, it has another more important in practice deficiency: 
Example(Any) would be incompatible with Example(TInteger); this seems not 
acceptable.

And variant records are certainly not applicable here, as I deal with 
(tagged) private types which contain a C pointer only.

>> Moreover, bindings may contain more than one row of values which can be
>> enumerated like an iterator. I am not sure if this can be expressed in
>> terms of a variant record.
> 
> Variant records can have discriminants, too. (In fact, discriminants are
> half of how variant-records do their thing, the other half being the
> "internal case statement/construct".)
> 
>> The proposed feature increases reliability of programming. It is
>> undoubtful that adding more type invariants increases reliability.
> 
> I fail to see how you couldn't achieve this by use of (a) variant records,
> and (b) constrained subtypes.
> 
> eg:
>   SubType Integer_Example is Example( TInteger );
>   Function X(Input : Integer) Return Integer_Example;
-- 
Victor Porton - http://portonvictor.org