From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,bf608b8936d68540
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.66.67.37 with SMTP id k5mr7150482pat.22.1367830779359;
        Mon, 06 May 2013 01:59:39 -0700 (PDT)
Path: 
 bp1ni1673pbd.1!nntp.google.com!news.glorb.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail
From: Stephen Leake <stephen_leake@stephe-leake.org>
Newsgroups: comp.lang.ada
Subject: Re: Accessing finalized values
References: <143a8db3-c14b-4983-a481-4b998aea42af@googlegroups.com>
 	<km1e4q$j98$1@munin.nbi.dk>
 	<7a248ba5-9fbc-4326-bbb8-eec3c125d455@googlegroups.com>
Date: Mon, 06 May 2013 03:59:36 -0500
Message-ID: <85r4hk7abr.fsf@stephe-leake.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt)
Cancel-Lock: sha1:/J2cflCgWBwkabUY9QXotHnIhKA=
MIME-Version: 1.0
X-Complaints-To: abuse@flashnewsgroups.com
Organization: FlashNewsgroups.com
X-Trace: 29066518770fbc7c1c72704075
X-Received-Bytes: 2211
Content-Type: text/plain
Date: 2013-05-06T03:59:36-05:00
List-Id: <comp.lang.ada>

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