|
|
In a separate email I suggested deprecating
FileReference>>openWritable: (I'm still planning to submit a PR), but on
further inspection...
Does anyone know the history and plans for File and FileHandle?
The comments for FileHandle to me suggest it is a layer between a stream
and the primitives (FilePlugin). But as far as I can tell, it is never
used. The stream creation methods in FileReference (readStream,
writeStream, binaryReadStream, binaryWriteStream) use FileHandle during
the stream creation, but the end result doesn't actually include a
FileHandle. The main method called (in the case of the write variants)
is:
--
FileHandle>>binaryWriteStream
^ (File named: reference fullName) writeStream
--
which obviously doesn't actually need FileHandle at all.
Streams have a handle, but it is a ByteArray, which is the associated
SQFile structure used by the VM.
Presumably the intention was that the streams would hold on to a
FileHandle, which would keep the ByteArray. This makes sense since it
gives us an object that can take responsibility for some operations (as
opposed to using a ByteArray as the handle).
On the other side, the class comment for File says:
--
I represent a sequential binary File. I provide the minimum operations to:
- move the cursor fo the file
- reading
- writing
...
--
And then goes on to mention several methods that aren't actually
implemented, e.g. seekAbsolute:, seekRelative:, nextPutAll:, next:, etc.
It ends up just being a set of utility methods to facilitate the
creation of streams.
It would be great if someone is able to fill in the gaps. If not, I can
think of two paths we can take (apart from leaving things as they are,
which seems a bit messy):
1. Remove (deprecate) both File and FileHandle and move the
responsibility of creating the BinaryFileStream to the FileSystemStore.
2. Make FileHandle really responsible for representing an open file and
modify streams, etc., to use FileHandle.
I prefer the second approach as it provides more granular responsibility
and a natural place to put functionality that is not directly stream
related (as an example, I'm planning to extend the file attributes
functionality so we can stat() an open file to find out the mode, etc.).
But I'd want to think about the performance implications of adding a
layer between streams and FilePluginPrims.
What am I missing?
Cheers,
Alistair
|
Locked
