Smalltalk › Pharo › Pharo Smalltalk Developers

Pharo FIleSystem Compatibility with Gemstone's FileSystemGs

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Pharo Smalltalk Developers mailing list

Pharo FIleSystem Compatibility with Gemstone's FileSystemGs

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.

Areas of exploration to date have been:

Replacement of File with GsFile - in Gemstone we want to use the native file class.
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

FileReadWriteBinaryMode

FileReadWriteTruncatedMode

FileReadWriteTruncatedBinaryMode

FileWriteMode

FileWriteBinaryMode

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)

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:

Thanks for your help.

Reg

Guillermo Polito

Re: Pharo FIleSystem Compatibility with Gemstone's FileSystemGs

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 <[hidden email]> 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 :)

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

Sven Van Caekenberghe-2

Re: Pharo FIleSystem Compatibility with Gemstone's FileSystemGs

> On 12 Dec 2018, at 13:21, Guillermo Polito <[hidden email]> 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 <[hidden email]> 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