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: > > 1. 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? > > 1. 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 :) 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. > > - 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 >
