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
>>>
>>
>