About cr and lf

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

About cr and lf

Stephane Ducasse-3
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?

Stef

Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

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

Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

Guillermo Polito
But the question is: what does cr do?

 - Does it write a platform independent newLine?
 - Or does it write a (platform dependent) cr ascii character?


On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <[hidden email]> 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
>




--

   

Guille Polito


Research Engineer

French National Center for Scientific Research - http://www.cnrs.fr



Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

Stephane Ducasse-3
In reply to this post by Jan Vrany
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.

Stef

On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <[hidden email]> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

EstebanLM

> On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

tesonep@gmail.com
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" <[hidden email]> wrote:

> On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

melkyades
In reply to this post by EstebanLM
or eol

On Fri, Aug 4, 2017 at 9:19 AM, Esteban Lorenzano <[hidden email]> wrote:

> On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>





--
Javier Pimás
Ciudad de Buenos Aires
Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

Damien Pollet
In reply to this post by tesonep@gmail.com
I agree with Pablo, #cr and #lf should not be clever and just be names for the carriage return and linefeed characters/codepoints.

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, [hidden email] <[hidden email]> 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" <[hidden email]> wrote:

> On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

EstebanLM

On 4 Aug 2017, at 15:41, Damien Pollet <[hidden email]> 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, [hidden email] <[hidden email]> 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" <[hidden email]> wrote:

> On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

Stephane Ducasse-3
In reply to this post by tesonep@gmail.com
Yes :)


On Fri, Aug 4, 2017 at 2:25 PM, [hidden email] <[hidden email]> 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" <[hidden email]> wrote:
>>
>>
>> > On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]>
>> > 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 <[hidden email]>
>> > 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
>> >>>
>> >>
>> >
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

Peter Uhnák
In reply to this post by Damien Pollet
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, [hidden email] <[hidden email]> 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" <[hidden email]> wrote:
> >
> >>
> >> > On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]>
> >> 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 <[hidden email]>
> >> 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

Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

Jan Vrany
In reply to this post by Stephane Ducasse-3
On Fri, 2017-08-04 at 14:06 +0200, Stephane Ducasse 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.

Yes, that's exactly what I meant.

cr
   self newLine

Jan

>
> Stef
>
> On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <[hidden email]>
> 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
> > >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

gcotelli
In reply to this post by Stephane Ducasse-3
I vote for:

#cr and #lf just put this character in the stream.
#newLine put the underlying OS line ending.

This is consisten also with String>>expandMacrosWithArguments:
<r> -> cr
<l> -> lf
<n> -> OSPlatform current lineEnding

On Fri, Aug 4, 2017 at 7:03 AM, Stephane Ducasse <[hidden email]> 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?

Stef


Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

Damien Pollet
In reply to this post by Peter Uhnák
On 4 August 2017 at 18:52, Peter Uhnak <[hidden email]> wrote:
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.

Hmm, granted :)
 
I think that most WriteStream miss what MultiByteFileStream has -- lineEndConvention.

fileStream lineEndConvention: #lf.

Agreed.
 
fileStream cr. "<- this will be autoconverted to #lf"

No… please don't abuse a low-level explicit selector to mean something context-dependent.

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.

But it's ugly…
 
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"

Yes, I actually prefer that to my own proposition, just don't make #cr and #lf contextually put something else than their name implies.

#newline (or #nl if you prefer it concise) should be the contextual message

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet
Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

Tudor Girba-2
In reply to this post by EstebanLM
+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 <[hidden email]> wrote:
>
>
>> On 4 Aug 2017, at 15:41, Damien Pollet <[hidden email]> 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, [hidden email] <[hidden email]> 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" <[hidden email]> wrote:
>>
>> > On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: About cr and lf

EstebanLM
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 <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>> On 4 Aug 2017, at 15:41, Damien Pollet <[hidden email]> 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, [hidden email] <[hidden email]> 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" <[hidden email]> wrote:
>>>
>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: About cr and lf

Alistair Grant
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 <[hidden email]> 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 <[hidden email]> wrote:
> >>
> >>
> >>> On 4 Aug 2017, at 15:41, Damien Pollet <[hidden email]> 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, [hidden email] <[hidden email]> 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" <[hidden email]> wrote:
> >>>
> >>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

EstebanLM

> On 5 Aug 2017, at 11:06, Alistair Grant <[hidden email]> wrote:
>
> 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.

heh, me too… but is a bit cryptic.

>
> Cheers,
> Alistair
>
>
>>> On 4 Aug 2017, at 23:48, Tudor Girba <[hidden email]> 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 <[hidden email]> wrote:
>>>>
>>>>
>>>>> On 4 Aug 2017, at 15:41, Damien Pollet <[hidden email]> 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, [hidden email] <[hidden email]> 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" <[hidden email]> wrote:
>>>>>
>>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

Alistair Grant
On Sat, Aug 05, 2017 at 11:09:51AM +0200, Esteban Lorenzano wrote:

>
> > On 5 Aug 2017, at 11:06, Alistair Grant <[hidden email]> wrote:
> >
> > 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.
>
> heh, me too... but is a bit cryptic.


#nl
    "Insert the platform dependent end of line character.
    For people that haven't got used to terminal communications rising
    above 9600baud"

    ^self newLine



:-)


Reply | Threaded
Open this post in threaded view
|

Re: About cr and lf

EstebanLM

On 5 Aug 2017, at 11:14, Alistair Grant <[hidden email]> wrote:

On Sat, Aug 05, 2017 at 11:09:51AM +0200, Esteban Lorenzano wrote:

On 5 Aug 2017, at 11:06, Alistair Grant <[hidden email]> wrote:

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.

heh, me too... but is a bit cryptic.


#nl
   "Insert the platform dependent end of line character.
   For people that haven't got used to terminal communications rising
   above 9600baud"

   ^self newLine

+1




:-)

12