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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13