Re: file-handles

[John Darrington]

I can understand where you're comming from.  How would you feel about
the GUI just re-using the same file handle?  In many ways that would
make more sense, because currently, whenever the GUI opens a new file,
I'm destroying the old file handle, and immediately recreating it,
which seems cumersome.  So can you see any problem with a function
which associates a new filename with a handle.  Perhaps it would have
to do some checks first, like closing the old file if it was open.

J'

On Sun, Jan 22, 2006 at 10:12:07AM -0800, Ben Pfaff wrote:
     
     The only real concern I have with reintroducing a destruction
     function is the possibility of freeing an in-use file handle.  In
     syntax:
     
             FILE HANDLE FOO...
             DATA LIST (or another command using FOO)
             ...somehow FOO gets destroyed...
             EXECUTE
     
     The EXECUTE will actually run the DATA LIST, at which time FOO
     will be dereferenced despite having been destroyed.  That's one
     reason there's no DESTROY FILE HANDLE command.  Now if there's no
     possibility that the GUI will do that, then it makes sense to let
     the GUI destroy its file handle.
     
     I'm actually working on a reference-counting scheme that will
     allow destroying file handles safely, but if your code is
     destruction-safe then feel free to reintroduce a "free" function
     for now.

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature