Hi Esteban,

On Sat, Aug 05, 2017 at 11:30:58AM +0200, Esteban Lorenzano wrote:
> 
> > On 5 Aug 2017, at 11:17, Peter Uhnak <i.uh...@gmail.com> wrote:
> > 
> >> I think there is a consensus we need to keep #cr and #lf as intended
> > 
> > Is there?
> > 
> > My argument was that there's no (obvious) reason to combine different line 
> > endings in the same document. Therefore if you were to use #cr, #lf, #crlf, 
> > you would actually mean that you just want to enter newline.
> 
> no, sometimes you want to enforce a specific line ending. You will not mix, 
> but you will not use the one from platform. Also, sometimes you actually can 
> use #cr and #lf different as their immediate, common use (I???ve seen some 
> weird exporting formats).
> 
> > 
> > Similar problem arises when you would write a multiline string:
> > 
> > stream nextPutAll: 'first line with enter
> > second line'.
> > 
> > Stored in method this will most likely contain Pharo's internal 
> > representation (#cr), even though you just want a new line, and not 
> > specifically #cr. (I've lost count how many times tests on CI failed 
> > because of this.)

I think Peter raises a good point about how strings with embedded line
endings are written out.  We do need to ensure that this case is handled
sensibly in the new scheme.  (Maybe the proposed scheme already handles
this correctly, I don't know, but it should be an explicit test).

Cheers,
Alistair


> > Considering the above, my opinion is:
> > 
> > 1) by default #cr, #lf, #crLf, #nl (#newLine) will write whatever is 
> > globally configured for the stream (#beFor*)
> 
> No, I strongly disagree. 
> #cr and #lf are ascii characters and should not be redefined. 
> 
> > 2) if one wanted to combine different line endings in the same stream, 
> > there should be an option to disable autoconversion. 
> > (Stream>>noNewLineAutoconversion)
> > 
> > If (1) is much more common than (2), then imho autoconversion should cause 
> > no issues.
> > If (1) is NOT that much more common than (2), then autoconversion wouldn't 
> > be beneficial.
> > 
> > Autoconversion could also make transition easier because existing code will 
> > suddenly work as intended here without breaking anything (hopefully).
> 
> Sorry, I do not see what this approach solves than the other one does not 
> (and as I see, this one is a lot more complicated and prone to confusion).
> 
> cheers, 
> Esteban

Reply via email to