On Fri, Aug 04, 2017 at 03:41:05PM +0200, Damien Pollet wrote:
Stream >> newLineForWindows "convenience for the most common platforms Stream >> newLineForUnix Stream >> newLineForHistoricReasons
Practically speaking this looks insanely wordy. In 102% (est.) you want to use the same consistent newline and not thinking about for which platform you are writing every time you want to write a new line. I think that most WriteStream miss what MultiByteFileStream has -- lineEndConvention. fileStream lineEndConvention: #lf. fileStream cr. "<- this will be autoconverted to #lf" Also I would like to see a situation where you actually _want_ to use different line endings at the same time, so converting lf/cr to the global one shouldn't break things. So maybe instead of stating what kind of line ending you want to write, you would specify them for the whole stream
Stream >> newLineForWindows "convenience for the most common platforms Stream >> newLineForUnix Stream >> newLineForHistoricReasons
Stream>>beForCurrentPlatform (would be the default maybe?) Stream>>beForWindows "crlf" Stream>>beForUnix "lf" Stream>>beAnnoyingOutsideOfPharo "cr" Peter
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@gmail.com <tesonep@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@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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@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