> On 4 Aug 2017, at 15:41, Damien Pollet <[email protected]> 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, [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>> 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" <[email protected] > <mailto:[email protected]>> wrote: > > > On 4 Aug 2017, at 14:06, Stephane Ducasse <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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>
