I am a little confused by Filestreams.MD
#position and #position: report and set the number of past items.
So when you open a stream, #position is 0. So why does the first
"Positionable streams" example use ... position: 4 ... while the
second one skips 3 characters? ... position: 3 ... would be
just as broken.
Oh, I think a clarification is needed when talking about UTF-8.
To the best of my knowledge you don't need a Byte-Order-Mark at
the beginning of a UTF-8 stream because there is no byte order
issue to result, but apparently many Windows programs like to
add one. Does/will Pharo add one when writing a UTF-8 file?
Does/will it skip one when reading a UTF-8 file?
I find the new approach produces unattractive code. I can do
all of the examples simply in a system that
(a) implements the ANSI Smalltalk FileStream class methods
(b) supports '/dev/stdin' and '/dev/stdout' as file names
(c) interprets the external type #'text' either as #'utf8'
or as "whatever $LC_CTYPE says" and also supports #'utf8'
and #'cp1250' as external types.
Oh, and defines
Object>>bindOwn: aBlock
^(self respondsTo: #close)
ifTrue: [aBlock ensure: [self close]]
ifFalse: [aBlock value]
What document should I read to get a mental model of the new
system and understand its rationale?
On 23 July 2018 at 19:38, Pavel Krivanek <pavel.kriva...@gmail.com> wrote:
> Hello,
>
> I've prepared a draft of a short document that should help you with the
> transition to the "new" file streams API in Pharo 7.
>
> https://github.com/pavel-krivanek/pharoMaterials/blob/
> master/Filestreams.MD
>
> Pull requests are welcome.
>
> Cheers,
> -- Pavel
>
>
>
>
