Very good initiative! It's worth a few hick-ups. 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 <s...@stfx.eu>: > 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 > > > > > >
