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
_______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
