Re: Accessing finalized values

[Stephen Leake <stephen_leake@stephe-leake.org>]

sbelmont700@gmail.com writes:

> On Friday, May 3, 2013 6:36:08 PM UTC-4, Randy Brukardt wrote:
>> 
>> This is perfectly legitimate, although arguably pathological.
>>
>
> Pathological seems like an understatement; it seems like a pretty
> major catch-22. If the whole purpose of Finalize is "to ensure that
> proper cleanup is performed prior to the object becoming permanently
> inaccessible", but its perfectly legitimate to access the object after
> Finalize has been called, then writing 110% bulletproof code becomes
> much more complex. How is an object supposed to free its resources if
> the resources must still be made available?

The fact that Finalize is called a second time does _not_ mean the
resources must still be available; it means the rest of the program was
unable to keep proper track of whether Finalize had yet been called.

So it is perfectly fine to do something like:

procedure Finalize (Item : my_type)
is begin
   if Item.Finalized then
      ;; nothing more to do
      return;
   else
      ;; free stuff etc
      ...
   end if;
end Finalize;

> For instance, suppose finalization for a File type closes the file; if
> it has to assume that other code might call Read and Write subprograms
> after Finalize has been executed, 

It does _not_ have to assume that; it only has to assume that Finalize
might be called again, not any other operation.


-- 
-- Stephe