> On 15 Mar 2018, at 23:36, Nicolas Cellier 
> <[email protected]> wrote:
> 
> Very good initiative!
> It's worth a few hick-ups.

Thanks, the really hard work is in the all the using code, writing against 
simpler APIs.

It will be a while before all the dust settles and all performance issues are 
covered, but we are already quite far.

> I've tried to reduce RWBinaryOrTextStream usage in Squeak maybe 10 years ago, 
> but you know it very well, the last places which are resisting are the more 
> intricated and convoluted.
> I call it the SwiisKnifeStream and allways wandered why we would have to 
> carry so many subclasses of Stream, since we have one capable of almost 
> everything!
> Managing the states in such a hierarchy was an art, if ever torture is an 
> art... and we are loosing a great can of worms for fishing the bugs.
> So, R.I.P. and no regret!
> 
> 2018-03-15 21:01 GMT+01:00 Sven Van Caekenberghe <[email protected]>:
> Executive Summary of the recent FileStream Changes
> 
> In Pharo 7 Guille Polito recently committed a heroic set of changes that we 
> were planning to do for a long time but were afraid to take on.
> 
> The idea is to replace a couple of fat, overly complex, multi-functional, 
> do-all classes with a set of simpler single purpose classes that can be 
> combined as needed.
> 
> The classes that we want to get rid of can be found in the package 
> DeprecatedFileSystem, in particular FileStream, StandardFileStream, 
> MultiByteFileStream, MultiByteBinaryOrTextStream and RWBinaryOrTextStream.
> 
> The replacements are can be found in packages Files and 
> Zinc-Character-Encoding-Core.
> 
> Encoding and decoding characters to and from bytes is done using classes that 
> you wrap around a more primitive binary stream. The same goes for buffering 
> or translating line endings.
> 
> For example,
> 
>  '/Users/sven/Desktop/foo.txt' asFileReference binaryReadStream.
> 
> gives you a ZnBufferedWriteStream wrapping a BinaryWriteStream.
> 
> While,
> 
>  '/Users/sven/Desktop/foo.txt' asFileReference readStream.
> 
> gives a ZnCharacterReadStream wrapping a ZnBufferedWriteStream wrapping a 
> BinaryWriteStream.
> 
> To translate line endings, we would wrap a ZnCharacterWriteStream using a 
> ZnCrPortableWriteStream.
> 
> There are a couple of more specialised streams to cover special cases (like 
> read and writing at the same time).
> 
> SocketStream remains another fat, overly complex, multi-functional, do-all 
> class, for which usable replacements exist in the form of ZdcSocketStream and 
> ZdcSecureSocketStream, which are simpler, cleaner and binary only.
> 
> Of course, switching is more than replacing one class with a 100% compatible 
> alternative, that would give us the same complex result. The challenge is to 
> use a simpler API as well, to rethink how the streams are used. You know, 
> KISS.
> 
> Of course, we are far from done and need more testing, debugging and help 
> from as many people as possible.
> 
> Sven
> 
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 
> 
> 


Reply via email to