Hi,
just to (hopefully) clarify my intention, maybe pseudocode would describe my
thoughts better.
Stream>>beForWindows
"Use consistenly Windows line endings (CRLF) in the stream"
self convertLineEndings: true
lineEnding := String crlf
Stream>>convertLineEndings: aBoolean
"automatically convert line endings to the predefined one"
convertLineEndings := aBoolean
Stream>>nl
self nextPutAll: lineEnding
Stream>>cr
convertLineEndings ifTrue: [
self deprected: 'Using #cr/#lf for generic newlines is
deprected, use #nl instead".
self nl.
] ifFalse: [
self nextPutAll: String cr.
]
So when "convertLineEndings = true", then using anything else than #nl would
warn the user that they should use #nl instead (as they explicitly requested to
have the line endings consistend).
And when "convertLineEndings = false", it would behave pretty much the same way
as now, #cr would write #cr, etc.
With such approach imho
* output of existing code wouldn't be broken
* when switching to new scheme (#nl) the programmer would be warned where the
missed a change
* it will be easier to keep the newlines consistent
Peter
On Sat, Aug 05, 2017 at 11:30:58AM +0200, Esteban Lorenzano wrote:
>
> > On 5 Aug 2017, at 11:17, Peter Uhnak <i.uh...@gmail.com> wrote:
> >
> >> I think there is a consensus we need to keep #cr and #lf as intended
> >
> > Is there?
> >
> > My argument was that there's no (obvious) reason to combine different line
> > endings in the same document. Therefore if you were to use #cr, #lf, #crlf,
> > you would actually mean that you just want to enter newline.
>
> no, sometimes you want to enforce a specific line ending. You will not mix,
> but you will not use the one from platform. Also, sometimes you actually can
> use #cr and #lf different as their immediate, common use (I’ve seen some
> weird exporting formats).
>
> >
> > Similar problem arises when you would write a multiline string:
> >
> > stream nextPutAll: 'first line with enter
> > second line'.
> >
> > Stored in method this will most likely contain Pharo's internal
> > representation (#cr), even though you just want a new line, and not
> > specifically #cr. (I've lost count how many times tests on CI failed
> > because of this.)
> >
> > Considering the above, my opinion is:
> >
> > 1) by default #cr, #lf, #crLf, #nl (#newLine) will write whatever is
> > globally configured for the stream (#beFor*)
>
> No, I strongly disagree.
> #cr and #lf are ascii characters and should not be redefined.
>
> > 2) if one wanted to combine different line endings in the same stream,
> > there should be an option to disable autoconversion.
> > (Stream>>noNewLineAutoconversion)
> >
> > If (1) is much more common than (2), then imho autoconversion should cause
> > no issues.
> > If (1) is NOT that much more common than (2), then autoconversion wouldn't
> > be beneficial.
> >
> > Autoconversion could also make transition easier because existing code will
> > suddenly work as intended here without breaking anything (hopefully).
>
> Sorry, I do not see what this approach solves than the other one does not
> (and as I see, this one is a lot more complicated and prone to confusion).
>
> cheers,
> Esteban
>
> >
> > Peter
> >
> >
> > On Sat, Aug 05, 2017 at 10:49:02AM +0200, Esteban Lorenzano wrote:
> >> I think there is a consensus we need to keep #cr and #lf as intended, yet
> >> to add some kind of #newLine (which btw is different to EOL :P)
> >> vocabulary, isn’t?
> >>
> >> In this, I favour Peter approach for define line ending convention (the
> >> way #newLine will work)… and of course by default it should use the one
> >> from the current platform.
> >>
> >> anything agains this approach?
> >>
> >> Esteban
> >>
> >>
> >>> On 4 Aug 2017, at 23:48, Tudor Girba <tu...@tudorgirba.com> wrote:
> >>>
> >>> +1.
> >>>
> >>> We need a basic representation of those characters. Logical ones should
> >>> be derived from the simple ones.
> >>>
> >>> Doru
> >>>
> >>>
> >>>> On Aug 4, 2017, at 3:44 PM, Esteban Lorenzano <esteba...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>
> >>>>> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pol...@gmail.com> wrote:
> >>>>>
> >>>>> I agree with Pablo, #cr and #lf should not be clever and just be names
> >>>>> for the carriage return and linefeed characters/codepoints.
> >>>>
> >>>> +1
> >>>>
> >>>>>
> >>>>> Making #newLine's behavior dependent on the current platform disturbs
> >>>>> me, though. I'd rather have:
> >>>>>
> >>>>> Stream >> newLineFor: platform
> >>>>> self nextPutAll: platform lineEnding
> >>>>>
> >>>>> Stream >> newLineForCurrentPlatform
> >>>>> self newLineFor: OSPlatform current
> >>>>>
> >>>>> Stream >> newLineForWindows "convenience for the most common platforms
> >>>>> Stream >> newLineForUnix
> >>>>> Stream >> newLineForHistoricReasons
> >>>>>
> >>>>> Stream >> newLine
> >>>>> "delegates to one of the above, I'd argue for unix for convenience,
> >>>>> but windows is the technically correct combination of cr + lf, and cr
> >>>>> only is the historic one"
> >>>>>
> >>>>>
> >>>>> On 4 August 2017 at 14:25, teso...@gmail.com <teso...@gmail.com> wrote:
> >>>>> To me it is clear that cr and lf should be in streams. But they should
> >>>>> put the 'cr' or 'lf' character only. And of course the platform
> >>>>> independent newline should be also.
> >>>>>
> >>>>> The first (cr, lf) should be used by the code wanting to have absolute
> >>>>> control of what is in the stream. The later (newline) when you just
> >>>>> want a new line.
> >>>>>
> >>>>> The two have completely different behaviour, ones are really low level,
> >>>>> the other is higher level.
> >>>>>
> >>>>> On 4 Aug 2017 14:20, "Esteban Lorenzano" <esteba...@gmail.com> wrote:
> >>>>>
> >>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.s...@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Well. This is not implemented like that in Pharo.
> >>>>>>
> >>>>>> cr is bad because it does not mean that it is independent of the
> >>>>>> platform.
> >>>>>> So cr can be redefined as newLine and keep but not used inside the
> >>>>>> system.
> >>>>>
> >>>>> sometimes you actually want to write a cr (or a lf). So it needs to
> >>>>> remain in the system, of course.
> >>>>> now, including #newLine can be cool (most of the times you want the
> >>>>> “platform compatible” new line). Also I would consider including #nl,
> >>>>> abbreviated… just for convenience :P
> >>>>>
> >>>>> Esteban
> >>>>>
> >>>>>>
> >>>>>> Stef
> >>>>>>
> >>>>>> On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <jan.vr...@fit.cvut.cz>
> >>>>>> wrote:
> >>>>>>> On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote:
> >>>>>>>> Hi guys
> >>>>>>>>
> >>>>>>>> While writing pillar code, I ended up using "stream cr" and it
> >>>>>>>> worries
> >>>>>>>> me to still expand usage
> >>>>>>>> of a pattern I would like to remove.
> >>>>>>>>
> >>>>>>>> Let us imagine that we would like to prepare the migration from cr.
> >>>>>>>> I was thinking that we could replace cr invocation by newLine so that
> >>>>>>>> after newLine
> >>>>>>>> could be redefined as
> >>>>>>>>
> >>>>>>>> Stream >> newLine
> >>>>>>>> self nextPutAll: OSPlatform current lineEnding
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> what do you think about this approach?
> >>>>>>>
> >>>>>>> Why not? But please keep #cr.
> >>>>>>>
> >>>>>>> Section 5.9.4.1 of ANSI reads:
> >>>>>>>
> >>>>>>> Message: cr
> >>>>>>>
> >>>>>>> Synopsis
> >>>>>>> Writes an end-of-line sequence to the receiver.
> >>>>>>>
> >>>>>>> Definition: <puttableStream>
> >>>>>>> A sequence of character objects that constitute the implementation-
> >>>>>>> defined end-of-line sequence is added to the receiver in the same
> >>>>>>> manner as if the message #nextPutAll: was sent to the receiver with
> >>>>>>> an argument string whose elements are the sequence of characters.
> >>>>>>>
> >>>>>>> Return Value
> >>>>>>> UNSPECIFIED
> >>>>>>> Errors
> >>>>>>> It is erroneous if any element of the end-of-line sequence is an
> >>>>>>> object that does not conform to the receiver's sequence value type .
> >>>>>>>
> >>>>>>> my 2c,
> >>>>>>>
> >>>>>>> Jan
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Stef
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Damien Pollet
> >>>>> type less, do more [ | ] http://people.untyped.org/damien.pollet
> >>>>
> >>>
> >>> --
> >>> www.tudorgirba.com
> >>> www.feenk.com
> >>>
> >>> "Presenting is storytelling."
> >>>
> >>>
> >>
> >>
> >
>
>
