comp.lang.ada
 help / color / mirror / Atom feed
From: sbelmont700@gmail.com
Subject: Re: Accessing finalized values
Date: Sun, 5 May 2013 08:00:18 -0700 (PDT)
Date: 2013-05-05T08:00:18-07:00	[thread overview]
Message-ID: <7a248ba5-9fbc-4326-bbb8-eec3c125d455@googlegroups.com> (raw)
In-Reply-To: <km1e4q$j98$1@munin.nbi.dk>

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?  

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, the file must stay open and the point is moot (or it must add preconditions to every operation).  It would seem like the same rules for protected types should apply to non-protected types as well, for all the same reasons.

-sb



  reply	other threads:[~2013-05-05 15:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-02 21:00 Accessing finalized values sbelmont700
2013-05-02 22:47 ` Adam Beneschan
2013-05-03 22:36 ` Randy Brukardt
2013-05-05 15:00   ` sbelmont700 [this message]
2013-05-06  5:45     ` J-P. Rosen
2013-05-06  8:59     ` Stephen Leake
2013-05-06  9:52     ` Dmitry A. Kazakov
2013-05-06 20:05       ` sbelmont700
2013-05-07  0:51         ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox