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 <[email protected]> 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 <[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." > >
