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?