[Pharo-users] Pharo 7 streams API

Richard O'Keefe raoknz at gmail.com
Mon Jun 25 10:56:10 EDT 2018


Experience with Java taught me to loath ethe "do I/O
by composing lots of little wrappers" approach for
several reasons:
 - the fact that the commonest case was not the
   default case, so that simple obvious code was
   somewhere between disgracefully slow and wrong
 - the extra complexity needed to get it right
   (having to know a plethora of wrapper classes
   instead of just getting sensible defaults)
 - the poor performance.

In my own Smalltalk system I hewed to the ANSI
Smalltalk standard and if you do
    FileStream read: aFileName
or  FileStream write: aFileName
you get a text file using the encoding set by
your environment's locale, the native line ending
convention, Simple, easy, and leaves Java's
I/O performance in the dust.

Of course wrappers are available for the rare
cases when you need them, but you don't _have_
to use them.  One reason this matters is that
there are two ways to write a stream:

  s2 := WrapperClass on: s1
    -- closing s2 just closes s2, not s1.
  s2 := WrapperClass onOwn: s1
    -- closing s2 closes s1 as well

And yes, both of these *are* used.


On 24 June 2018 at 04:53, Sven Van Caekenberghe <sven at stfx.eu> wrote:

> Peter,
>
> > On 23 Jun 2018, at 15:39, Peter Uhnák <i.uhnak at gmail.com> wrote:
> >
> > Hi,
> >
> > I'm starting to familiarize myself with new streams, and one thing I've
> noticed is the removal of #lineEndConvention (which I use all the time).
> >
> > So a statement like this
> >
> > aFile writeStreamDo: [ :stream |
> >       stream lineEndConvention: #lf.
> >       stream << '...'
> > ].
> >
> > has to be written like so
> >
> > aFile writeStreamDo: [ :rawStream | |stream|
> >       stream := (ZnNewLineWriterStream on: rawStream) forLf.
> >       stream << '...'
> > ].
> >
> > which feels very messy because I am mixing writing with the
> configuration. And I don't even take account for buffered/encoded
> decorators. Plus it increases the incidental complexity -- I need another
> variable, and I can accidentally write to the wrong stream, etc.
> >
> > Would a method like #writeStream:do: (or #writeStreamTransform:do:) make
> sense? E.g.
> >
> > aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on:
> stream) ] do: [ :stream |
> >       stream << '...'
> > ]
> >
> > To separate the composition from the usage?
> >
> > Thanks,
> > Peter
>
> The goals of the 'new' (they have existed for quite a while) streams is to
> go from single big complex do all classes and replace that with a
> composition of much simpler single purpose classes. Another goal is to
> reduce the API so that it becomes easier to create new stream classes. Of
> course, a consequence is that you need composition to get the functionality
> you want. But I think you understand the tradeoff.
>
> If the mixing of configuration/setup with writing/reading bothers you,
> then I would suggest using two methods. One that does only the
> writing/reading assuming a limited API, and another that does the
> configuration/setup, using composition.
>
> Note that the streams that you get already are a composition (most often a
> BinaryFileStream wrapped in a Buffered stream wrapped in a
> Encoding/Decoding stream). EOL translation is not a standard part of that.
> But there is quite some system code that does uses EOL translation.
>
> Sven
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20180626/b3bbaf7f/attachment.html>


More information about the Pharo-users mailing list