Re: Type invariants and private extensions?

[Shark8 <onewingedshark@gmail.com>]

On Tuesday, September 12, 2017 at 4:59:17 PM UTC-6, Victor Porton wrote:
> 
> 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.

What are you doing that you need to create an object w/o knowing the types? I've used the variant-record approach in several interpreters to excellent effect; I've also used tagged-type hierarchies, too.

Perhaps what would be more called for in your design is an abstract base type with a discriminant, then having the child-types use the proper value and using Base'Class variables/returns as needed:

  Type Base( Item_Type : Type_Enumeration ) is abstract tagged null record;
  Type Integer is new Base( TInteger ) with null record;
  Type Boolean is new Base( TBoolean ) with null record;
  --...

> 
> 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.
> 

I think you're tripping yourself up by overcomplicating / underelaborating on the design. Clear your mind, pull put a piece of paper, and in pen [so you can't erase] write a description of the system being careful to keep it consistent -- I find it very helpful nailing down a design. (In my experience how you're presenting things is how I feel when I haven't solidified a good design yet, and so things keep swirling out of control... kind of the infinite-loop version of "analysis paralysis".)

> 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.

Again, see the above.

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

That actually might be all the more reason to use them: C-pointers are notorious for being unsafe WRT type-safety... and a variant-record could certainly be used to isolate them and ensure that they are only used in the places they ought.