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
+1 I prefer #nl to #newLine, but admit that it is a subjective preference and that descriptive names are generally better. Cheers, Alistair > > 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
