[Pharo-dev] About cr and lf

Esteban Lorenzano estebanlm at gmail.com
Fri Aug 4 09:44:12 EDT 2017


> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet at 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, tesonep at gmail.com <mailto:tesonep at gmail.com> <tesonep at gmail.com <mailto:tesonep at 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" <estebanlm at gmail.com <mailto:estebanlm at gmail.com>> wrote:
> 
> > On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self at gmail.com <mailto:stepharo.self at 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.vrany at fit.cvut.cz <mailto:jan.vrany at 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 <http://people.untyped.org/damien.pollet>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170804/893169f4/attachment.html>


More information about the Pharo-dev mailing list