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.uhnak@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