Hi Monty We will keep the old stuff around in a kind of deprecated packages. Now in the long term we do not intend to maintain them forever because we will collapse under the load. You see it was either that clean up or modules.... so at the end ***Pharo*** should move on because this is our future.
In this vein, we are planning to migrate a selection of the old deprecated methods (of Pharo 30, 40, 50, 60) into a MigrationPackage with deprecatedWithTransform rule to help the migration of the old code to new one. Now of course nobody really stood up to give a hand. Normal this is easier to give us order :) Stef On Fri, Mar 16, 2018 at 7:05 AM, monty <[email protected]> wrote: > > >> 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 >> >> >> >> >> >> >
