+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 <[email protected]> wrote: > > >> 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] <[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]> wrote: >> >> > On 4 Aug 2017, at 14:06, Stephane Ducasse <[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]> 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."
