Re: Deallocation & Tagged Types

[chris <spamoff.danx@ntlworld.com>]

Robert I. Eachus wrote:
> 
> This is what Controlled types were added to the language for, why aren't 
> you using them?  In your example, if Vehicle is a controlled type, you 
> don't have a problem.  If Vehicle has no required finalization, it 
> doesn't need to be derived from Controlled (or Limited_Controlled) but 
> again, as the programmer of an abstraction that uses Vehicle, you don't 
> have to worry about it.

In the real code, the types *are* controlled.  The problem was how to 
get rid of X when X is of type access to Vehicle'Class, not how to tidy 
up X after use when it is a Vehicle.  I wasn't clear sorry.

I tried instantiating Unchecked_Deallocation on Vehicle and not 
Vehicle'Class not knowing you could do that.

> (Note:  I understand that if someone programs an abstraction 
> incorrectly, that is a problem.  But it is also a bug in the ADT that 
> needs to be fixed there.  Code that includes workarounds for bugs in the 
> ADTs used is twice wrong.  Once because the original type should be 
> corrected, and the second time because fixing the base abstraction is 
> now going to create a follow-on bug.)

Yes the ADT abstraction was broken, but only after trying to get around 
the problem of deallocating the access component in the record.  The 
ugliness is (IMO) gone now.


Chris