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 <[email protected]>
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 <[email protected]>:
> >>
> >> 2018-03-19 20:39 GMT+01:00 Esteban A. Maringolo <[email protected]>:
> >>>
> >>> 2018-03-19 16:32 GMT-03:00 Denis Kudriashov <[email protected]>:
>
> >>> > 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
