--- Begin Message ---
Forgot to copy the Pharo dev list.
Begin forwarded message:
> From: Reg Krock <rkro...@yahoo.ca>
> Subject: FileSystem and references to FIle
> Date: 8 January, 2019 at 2:05:15 PM EST
> To: Guillermo Polito <guillermopol...@gmail.com>, Sven Van Caekenberghe
> <s...@stfx.eu>
> Cc: Dale Henrichs <dale.henri...@gemtalksystems.com>, Martin McClure
> <martin.mccl...@gemtalksystems.com>
>
> Guille,
>
> As I have been working on porting FileStream to Gemstone, I have found that
> AbstractBinaryStream could be made more generic if the references to File
> were handled slightly differently. The idea is to delegate the call of File
> in AbstractBinaryStream to the instance side of File.
>
> For example:
> AbstractBinaryFIleStream >>#flush
> File flush: handle
>
> would be implemented as follows:
>
> AbstractBinaryFIleStream >>#flush
> file flush: handle
>
> File>>#flush: aHandle
> self class flush: aHandle
>
> From a compatibility perspective, GemStone would then also implement a
> GsFile>>#flush: and handle the flush as appropriate for GemStone.
>
> I have looked at the VA Smalltalk code as well and this would also work well
> with their code base.
>
> The methods that would need to be changed are:
> 1) AbstractBinaryFileStream
> atEnd
> flush
> next:intoBuffer:
> next:putAll:
> position
> position:
> readInto:startingAt:
> size
> sync
> 2) BinaryFileStream
> close
> closed
> truncate:
> 2) StdioStream
> next:
>
> Other references to File in the FileSystem classes, could the be changed to a
> FileSystem fileClass which would return the file class for the variation of
> Smalltalk.
> Pharo would return File, GemStone would return GsFile, VA Smalltalk would
> return CfsFileDescriptor.
>
> Your thoughts on this are greatly appreciated.
>
> Regards,
>
> Reg
>
--- End Message ---
