> On 12 Dec 2018, at 13:21, Guillermo Polito <[email protected]> wrote:
>
> Hi Reg,
>
> Thanks for your email, improving FileSystem is a cool thing ^^.
>
> On Tue, Dec 11, 2018 at 8:39 PM Reg Krock via Pharo-dev
> <[email protected]> wrote:
> Hi,
>
> I am working on making changes to FileSystemGs to make it work in Gemstone.
>
> Who is or the the persons to talk to about changes on the Pharo side.
>
> Well, I don't know if there is a single maintainer. I think that myself,
> Alistair, Sven, and many others can answer to questions on different aspects
> of file system.
> Anyways, I'd suggest you just send your emails to this mailing list, the
> person concerned/interested will answer when possible ;)
>
>
> Areas of exploration to date have been:
> • Replacement of File with GsFile - in Gemstone we want to use the
> native file class.
> How have you made it pluggable? This maybe requires the introduction of a
> backend or a separate store "GSFileSystemStore"?
> Does Gemstone require different kind of implementations for different
> platforms like linux/windows/osx or just a unix-like one is enough?
>
> • Introduction of a FileMode class hierarchy to replace the passing of
> they symbols #read and #write.
> • Added the proof of concept of FileMode with subclasses to be
> passed instead of #write and #read. The classes which have been introduced
> are:
>
> FileMode
> FileAppendMode
> FileAppendAndReadMode
> FileAppendAndReadBinaryMode
> FileAppendBinaryMode
> FileReadMode
> FileReadBinaryMode
> FileReadWriteMode
> FileReadWriteMode
> FileReadWriteBinaryMode
> FileReadWriteTruncatedMode
>
> FileReadWriteTruncatedBinaryMode
> FileWriteMode
> FileWriteBinaryMode
>
> I like the introduction of objects :)
me too
> What is the difference between the binary and non binary modes?
> How do you specify encoding for non binary ones? Or you assume ascii?
> Also, the fact that the "binary" aspect is repeated all over the hierarchy
> makes me think they could be composable aspects of a file mode.
indeed.
another remark: we are trying to move away (and mostly have) from streams that
are both readable and writeable at the same time - this is hardly ever needed
and complicates things a lot (socket/network streams being a bit of an
exception, although the reading and writing are independent there).
>
> • These classes return the appropriate mode string, (ex: ‘w+’)
> and know if the file is writable.Example of change - the text in blue shows
> the change.
>
> Exiting format:
> (filesystem open: aFileReference path
> writable: #write)
>
> Well, AFAIU, this is not public API (and it uses booleans to indicate "mode").
> Usually end users would simply do:
>
> aFileReference writeStream.
> aFileReference binaryWriteStream.
> aFileReference readStream.
> aFileReference binaryReadStream.
>
> But yes, I like also to model modes such as truncated, append, "force new".
>
>
> Proposed format:
> (filesystem open: aFileReference path
> writable: self store readWriteTruncatedMode)
>
> The #readWriteTruncatedMode method would return an instance of
> FileReadWriteTruncatedMode
>
> If a form of this proposal were to be adopted, then the appropriate methods
> should be renamed to have mode.
> As an example, #open:writeable: would become #open:mode:
>
> Well, we could keep the old API and build a higher level one on top, don't we?
>
> Do you have your code in a repository we could check?
>
>
> Thanks for your help.
>
> Thanks to you!
> Guille
>
> Reg
