Hi all,

First, we should not confuse "writing into a stream" with "writing into a
text file". Not all streams are to write into a text file. This means that
we cannot pretend that the basic stream implementation should always do a
conversion. I think that should belong to a text writer, also managing the
text encoding (utf-8 and so on). So far we have a Character writer stream
that wraps a binary stream and manages encoding (see
ZnCharacterWriteStream). I wrote for backwards compatibility
a ZnCrPortableWriteStream (that is in pharo repo so far because but should
be pushed back to Zinc's repo, hi Sven :) ) that manages crlf automatic
conversion also.

Moreover, for people that want "detection of line separators in a file"
such as it is done in text editors, I believe we need a higher level
abstraction. We need also to detect encoding and keep living during the
life of the file. However, we don't have such abstraction.

Guille

On Sat, Aug 5, 2017 at 8:03 PM, Alistair Grant <akgrant0...@gmail.com>
wrote:

> Hi Stef,
>
> On 5 August 2017 at 18:14, Stephane Ducasse <stepharo.s...@gmail.com>
> wrote:
> > So one step at a time:
> >
> > - #cr and #lf just put this character in the stream.
> > - #newLine put the underlying OS line ending. ( and sorry for the
> > nostalgic but nl sucks and to me this is netherlands and not newline
> > :).
>
> Beyond the nostalgic and humorous, there is actually a justification
> for the shorter #nl.
>
> Adding a new line is a common operation, and more compact code is more
> readable.  So I find:
>
> stream
>     << 'Line 1 goes here'; nl;
>     << 'Line 2 goes here'; nl.
>
> better than:
>
> stream
>     nextPutAll: 'Line 1 goes here'; newLine;
>     nextPutAll: 'Line 2 goes here'; newLine.
>
>
> Although this is still subjective.
>
> Cheers,
> Alistair
>
>
>
> > Then we should revisit all the cr inside the system and use newline.
> > Then we should think about the internal usage of cr by default in
> > Pharo (We should change it).
> >
> > Does it make sense?
> > Stef
> >
> >
> >
> > On Sat, Aug 5, 2017 at 4:08 PM, K K Subbu <kksubbu...@gmail.com> wrote:
> >> On Friday 04 August 2017 07:11 PM, Damien Pollet wrote:
> >>>
> >>> Stream >> newLineFor: platform
> >>>      self nextPutAll: platform lineEnding
> >>>
> >>
> >> EOL encoding is a property of a text file and not a platform. While
> files
> >> created on a certain proprietary platforms ;-) may use an encoding that
> does
> >> not make it a platform property. Pharo should be liberal in accepting
> and
> >> preserving differently encoded files. E.g. Text editor vim has a setting
> >> (fileformats) for eol encoding to view or edit files with cr or crlf EOL
> >> encoding. If this is not set, vim falls back to nl.
> >>
> >> I agree that existing messages like cr or nl should not be changed.
> Instead
> >> new methods (*eol) could be added to text files for decoding (read
> side) and
> >> encoding (write side). This should be liberal in accepting cr, nl, crnl
> >> decodes while reading a text file. While writing a new stream, eol
> should
> >> follow this order:
> >>       1. if file eol property is set (cr/nl/crnl) it should use it
> >>       2. else fallback to check platform eol property.
> >>       3. Else, use cr (for backward compatibility with old files)
> >> E.g.
> >>
> >>  (aStream atEOL) ifFalse: [ c := aStream next ]
> >>  aStream nextPutAll: 'hello world' ; writeEOL
> >>  record := aStream readLine. "strip eol"
> >>  aStream nextPutLine: 'hello world'
> >>
> >> This is not going to be an easy change but it would make new code
> cleaner.
> >>
> >> Regards .. Subbu
> >>
> >
>
>


-- 



Guille Polito


Research Engineer

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

Reply via email to