I should that I love twice the title of your email. - yes if we can have one good instead of multiple not so good. This is wonderful. Now I'm not expert in that and brain dead after car, flight, rer, metro, train to get back home
On Fri, Apr 20, 2018 at 5:24 PM, Sven Van Caekenberghe <[email protected]> wrote: > Hi, > > After the File and Stream changes in Pharo 7, a binary read, resp. write > stream from/to a file is actually a ZnBuffered(Read|Write)Stream on a > BinaryFileStream. You access these using #binary(Read|Write)Stream[Do:] sent > to a FileReference. > > As minimal streams the API of ZnBuffered(Read|Write)Stream was different from > what existed before. > > Specifically, a number of Integer decoding/encoding methods were missing. It > is probably best to add those (an alternative would be a subclass). > > When I looked at what was available, I thought I could improve upon the > current situation. In fact, I think all existing ones can be written in terms > of just one key method, one for reading and one for writing. The existing > methods than become simple aliases, all while offering more functionality. > > (Incidentally this would be an ideal use of a Trait, can we use them > again/still ?) > > The key method is #nextIntegerOfSize: numberOfBytes signed: signed bigEndian: > bigEndian [put: value] and can be found in the latest version of > Zinc-CharacterEncoding-Core with a comprehensive set of unit tests. > > For example, > > int32 > ^ self nextIntegerOfSize: 4 signed: true bigEndian: true > > nextWord > ^ self nextIntegerOfSize: 2 signed: false bigEndian: true > > or non-aliases ones like > > binaryStream nextIntegerOfSize: 3 signed: true bigEndian: false > > I think I nailed it, but I would love a second pair of eyes to check what I > did. > > The same functionality could be added to ByteArray in a slight variation > (with offsets), where similar integer encoding/decoding methods exist. > > Sven
