Re: [Pharo-project] Is the plan to replace FileStream by FSStream?
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 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
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
participants (2)
-
Henrik Johansen -
Stéphane Ducasse