On 12 Dec 2018, at 13:21, Guillermo Polito <guillermopolito@gmail.com> 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 <pharo-dev@lists.pharo.org> 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