> Sent: Thursday, March 15, 2018 at 4:01 PM > From: "Sven Van Caekenberghe" <[email protected]> > To: "Pharo Development List" <[email protected]> > Subject: [Pharo-dev] Executive Summary of the recent FileStream Changes > > 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.
StandardFileStream, at least, should remain for backwards compatibility and cross-platform compatibility with Squeak. It's a no-frills, non-decoding, non-LE normalizing stream that is heavily depended on. > 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. What do you think about this algorithm for encoding detection: http://www.yaml.org/spec/1.2/spec.html#id2771184 I have an implementation (with tests), if you're interested. (I was waiting to propose it until the FileSystem API switched over to using Zn streams and encoders. The TextConverter API doesn't support UTF-32.) > 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 > > > > > >
