Re: Accessing finalized values

["Randy Brukardt" <randy@rrsoftware.com>]

<sbelmont700@gmail.com> wrote in message 
news:56ae2d39-e3a1-4d3e-b9a1-8d4aa435ad8a@googlegroups.com...
On Monday, May 6, 2013 5:52:18 AM UTC-4, Dmitry A. Kazakov wrote:

>> Finalize is a hack.

I disagree with this...

>The more I delve into controlled types, the more I'm starting to come to 
>that
> conclusion.  This means, in general, that every controlled type must track 
> the
> state of its finalization and conditionally release resources (to 
> side-step the
> non-limited multiple finalization issue), as well as add a 'not 
> Is_Finalized'
> precondition to every single operation (to avoid access after 
> finalization)?
> Yuck.

...but disagree with this. And the main reason is that you have to be able 
to handle "non-open" objects in any case (consider files -- you have to 
already have some sort of check for an unopen file). So there is no problem 
to using that same check for objects that have been finalized.

For instance, in Claw, we have "invalid" objects, which is any object that 
exists, but has not yet been created or has previously been closed (which 
included finalization). Finalization releases resources making the object 
invalid. Every operation (other than Create, Close, and Finalize) have to 
check for whether the object is valid, and raise an exception if it is not. 
Care must be taken to avoid referencing any components if the object is 
invalid. There's certainly some level of complication to that, but it's 
unavoidable for any abstraction that has something like Create and/or Close.

It might be more of a problem for abstractions that don't have "Close", but 
even there there is usually an "empty" abstraction which also works fine. 
For instance, the Ada containers work this way: they're initialized to 
empty, and end up empty after finalization, and that's sufficient if the 
implementation can avoid using an extra resources for an empty container. 
(If you can't do this, the language requires raising an exception on use, so 
you'd have to have an extra flag and check.)

To summarize, it's a level of complication, but its one you're almost 
certainly going to have to deal with anyway. The main problem is that it 
makes most simplistic examples wrong - real examples need checks everywhere 
anyway (if they're a well-designed Ada abstraction).

                                              Randy.




-sb