Even before the refactoring, FileHandle was just using opening a file using a MultiByteFileStream. Probably FileHandle was originally thought as a clean replacement/façade of the old streams?
I don't know. On Thu, May 10, 2018 at 10:16 PM, Alistair Grant <[email protected]> wrote: > 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 > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
