Smalltalk › Pharo › Pharo Smalltalk Developers

Is the plan to replace FileStream by FSStream?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Luc Fabresse

Is the plan to replace FileStream by FSStream?

Hi,

reading this: http://code.google.com/p/pharo/issues/detail?id=5303

I wonder if the plan is to replace FileStream by FSStream?

#Luc

Camillo Bruni-3

Re: Is the plan to replace FileStream by FSStream?

there are some serious implications when doing so

The main issue arises from:
FileStream is 0 indexed
FSStream is 1 indexed

but we should reason about this and what to do exactly

On 2012-02-16, at 18:45, Luc Fabresse wrote:

> Hi,
>
> reading this: http://code.google.com/p/pharo/issues/detail?id=5303
> I wonder if the plan is to replace FileStream by FSStream?
>
> #Luc
>

Henrik Sperre Johansen

Re: Is the plan to replace FileStream by FSStream?

In reply to this post by Luc Fabresse

On Feb 16, 2012, at 6:45 PM, Luc Fabresse wrote:

Hi,

reading this: http://code.google.com/p/pharo/issues/detail?id=5303
I wonder if the plan is to replace FileStream by FSStream?

#Luc

My vote would be no.

http://forum.world.st/pharo-vision-tp4340345p4342871.html

http://forum.world.st/pharo-vision-tp4340345p4341445.html

You'd be stuck chasing bugs trying to bring FSFileStreams up to pair with the normal FileStreams for many, many releases.

I'd rather try one of the approaches mentioned in the 2nd link, setting StandardFileStream as the default plugged-in stream implementation, so you could rewrite the path API manipulation in your code independent of the stream/file reading/writing.

Cheers,

Henry

Camillo Bruni-3

Re: Is the plan to replace FileStream by FSStream?

ok, I guess we should take an action towards that direction...
I already had trouble enough getting it somehow compatible :), which should be fairly easy...

best
cami

On 2012-02-16, at 20:07, Henrik Johansen wrote:

> On Feb 16, 2012, at 6:45 PM, Luc Fabresse wrote:
>
>> Hi,
>>
>> reading this: http://code.google.com/p/pharo/issues/detail?id=5303
>> I wonder if the plan is to replace FileStream by FSStream?
>>
>> #Luc
>>
> My vote would be no.
> http://forum.world.st/pharo-vision-tp4340345p4342871.html
> http://forum.world.st/pharo-vision-tp4340345p4341445.html
>
> You'd be stuck chasing bugs trying to bring FSFileStreams up to pair with the normal FileStreams for many, many releases.
> I'd rather try one of the approaches mentioned in the 2nd link, setting StandardFileStream as the default plugged-in stream implementation, so you could rewrite the path API manipulation in your code independent of the stream/file reading/writing.
>
> Cheers,
> Henry

Henrik Sperre Johansen

Re: Is the plan to replace FileStream by FSStream?

In reply to this post by Luc Fabresse

On Feb 16, 2012, at 8:07 PM, Henrik Johansen wrote:

On Feb 16, 2012, at 6:45 PM, Luc Fabresse wrote:

Hi,

reading this: http://code.google.com/p/pharo/issues/detail?id=5303
I wonder if the plan is to replace FileStream by FSStream?

#Luc

My vote would be no.
http://forum.world.st/pharo-vision-tp4340345p4342871.html
http://forum.world.st/pharo-vision-tp4340345p4341445.html

You'd be stuck chasing bugs trying to bring FSFileStreams up to pair with the normal FileStreams for many, many releases.
I'd rather try one of the approaches mentioned in the 2nd link, setting StandardFileStream as the default plugged-in stream implementation, so you could rewrite the path API manipulation in your code independent of the stream/file reading/writing.

Cheers,
Henry

Let me put it another way:

FS is a really good, no, compared to what we have now, - excellent - API for specifying paths.

1) If we *ever* want people to start using it with existing code though, we need to decouple the task of rewriting path creation from that of also rewriting the code using streams opened on said paths.

2) By making the stream implementation used by FS pluggable you:

- Reduce the size of FS core, making it more focused on the actual FileSystem manipulation/querying part of the framework.

- Can still provide an ANSI stream implementation for people writing new, portable code.

- Solve #1, by letting existing users continue to use their, however flawed, existing stream implementations.

Cheers,

Henry

Stéphane Ducasse

Re: Is the plan to replace FileStream by FSStream?

Henrik

I'm sure that if we would be in face of a browser together I would get 100% what you are saying now I hate mail
but I'm not 100% clear about what you say. :)
Could you make a list of the steps that we could follow?
I will sit and discuss with camillo next week. I would like to have a todo so that I can do item after item…
Because I want to get rid of the old code.

Stef

On Feb 16, 2012, at 8:25 PM, Henrik Johansen wrote:

>
> On Feb 16, 2012, at 8:07 PM, Henrik Johansen wrote:
>
>>
>> On Feb 16, 2012, at 6:45 PM, Luc Fabresse wrote:
>>
>>> Hi,
>>>
>>> reading this: http://code.google.com/p/pharo/issues/detail?id=5303
>>> I wonder if the plan is to replace FileStream by FSStream?
>>>
>>> #Luc
>>>
>> My vote would be no.
>> http://forum.world.st/pharo-vision-tp4340345p4342871.html
>> http://forum.world.st/pharo-vision-tp4340345p4341445.html
>>
>> You'd be stuck chasing bugs trying to bring FSFileStreams up to pair with the normal FileStreams for many, many releases.
>> I'd rather try one of the approaches mentioned in the 2nd link, setting StandardFileStream as the default plugged-in stream implementation, so you could rewrite the path API manipulation in your code independent of the stream/file reading/writing.
>>
>> Cheers,
>> Henry
>
> Let me put it another way:
> FS is a really good, no, compared to what we have now, - excellent - API for specifying paths.
>
> 1) If we *ever* want people to start using it with existing code though, we need to decouple the task of rewriting path creation from that of also rewriting the code using streams opened on said paths.
>
> 2) By making the stream implementation used by FS pluggable you:
> - Reduce the size of FS core, making it more focused on the actual FileSystem manipulation/querying part of the framework.
> - Can still provide an ANSI stream implementation for people writing new, portable code.
> - Solve #1, by letting existing users continue to use their, however flawed, existing stream implementations.
>
> Cheers,
> Henry
>

Henrik Sperre Johansen

Re: Is the plan to replace FileStream by FSStream?

On Feb 16, 2012, at 9:56 PM, Stéphane Ducasse wrote:

> Henrik
>
> I'm sure that if we would be in face of a browser together I would get 100% what you are saying now I hate mail
> but I'm not 100% clear about what you say. :)
> Could you make a list of the steps that we could follow?
> I will sit and discuss with camillo next week. I would like to have a todo so that I can do item after item…
> Because I want to get rid of the old code.
>
> Stef

Replace FSFileStream & subclasses' references with something like an FSStreamProvider, where FSStreamProvider:
- delegates an API for returning different classes to use for #readStream, #writeStream etc. to a #currentProvider method.

For thread-safe switching on case-by-case basis:
- implement FSStreamProvider#currentProvider as thread-local lookup with FSStreamProvider CurrentProvider class var as backup.
- implement FSStreamProvider #useDuring: aBlock installing self in the thread-local var during execution of aBlock.

For use in Pharo:
- Implement a FSLegacyStreamProvider, set as CurrentProvider in Pharo. (Should return MultiByteFileStream for most instances)

For modularizing the current FSFileStreams:
- Revert compatibility fixes extending the API, move them to an independent package,and implement an FSAnsiStreamProvider or some such in that package.

Cheers,
Henry