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 <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
>> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Presenting is storytelling."
> 
> 


Reply via email to