On Fri, Apr 20, 2018 at 5:24 PM, Sven Van Caekenberghe <sven@stfx.eu> 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.

Sorry I arrive late.

I'm thinking that this is only valid for binary streams, putting it in buffered stream overloads the API... We can leave with it but... Two thoughts that come to my mind about this:

��- first, when we are decoding like that from a stream, we are probably parsing a binary format, so we want in general to have utility methods to read different sizes. Maybe we could include a Reader class with methods such as

�� ��* readSignedInt32

�� ��* readUnsignedInt32

�� ��* readSignedInt64

�� ��* readUnsignedInt64

�� ��* readFloat64

... and so on?

- Second, that Reader may be (or not) a new decorator alternative. ZnBinaryDecoder? Wrapping a binary (buffered or not) stream. And this would not overload the API ^^.

What do you think?

The same functionality could be added to ByteArray in a slight variation (with offsets), where similar integer encoding/decoding methods exist.

Sven

--

������

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: +33 06 52 70 66 13