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