> On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopol...@gmail.com> wrote:
> 
> Can somebody propose an implementation besides on top of this discussion? I 
> propose such an implementation should take the form of a stream decorator 
> instead of changing the base implementation.

YES, a decorator !

We want simpler streams, not the old complex ones. Less API, less functionality.

> Guille
> 
> On Sun, Aug 6, 2017 at 12:01 AM, Peter Uhnak <i.uh...@gmail.com> wrote:
> 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."
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
> >
> 
> 
> 
> 
> -- 
>    
> Guille Polito
> 
> Research Engineer
> French National Center for Scientific Research - http://www.cnrs.fr
> 
> 
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13


Reply via email to