Yes, it would be good to have those kind of methods. But there are some other constraints to have into account :)

�� - introducing these without introducing duplications is right now complicated because streams do not share a hierarchy

�� - having a common hierarchy is maybe complicated: ZnStreams should for the moment be backwards compatible with Pharo>4?

�� - using traits to avoid duplications would be good, but for now traits are forbidden from kernel packages

�� (otherwise we need to add traits in the kernel, + trait support in the class builder, runtime,... and the image will grow MBs and the build time will grow too)

About the naming, I'm for

��- #buffered / #bufferedWithBufferSize: size

��- #encoded / #utf8Encoded / #encodedAs: encoding

��- #usingCr / #usingLf��/ #usingCrLf��/ #usingPlatformLineEndingConvention /��#usingLineConvention: aConvention

On Mon, Mar 19, 2018 at 9:53 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

2018-03-19 17:42 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
> 2018-03-19 21:21 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
>>
>> 2018-03-19 20:39 GMT+01:00 Esteban A. Maringolo <emaringolo@gmail.com>:
>>>
>>> 2018-03-19 16:32 GMT-03:00 Denis Kudriashov <dionisiydk@gmail.com>:

>>> > aStream buffered.
>>> I'd only change this one, to #beBuffered.

>> But #be sounds like it modifies receiver.
>> But idea is same as #reversed or #sorted for collections.
> -1 for beBuffered, it's not about adding states to the stream.
> As Denis said, it's a transform producing a new stream.

I didn't understand it was returning a transformed instance, I
actually thought it was the opposite, so if that is the case then
Denis' suggested selectors are fine.

Thanks for the clarification.

Esteban A. Maringolo

��	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