2009/11/20 Stéphane Ducasse <[email protected]>:
> It was more on file streams or text when you edit a file.
> In particular this was in context of
>        http://code.google.com/p/pharo/issues/detail?id=1458
>
> Because before integrating it I wanted to know what it was about.
>
> Stef
>

Hi Stephane,

These changes just make it possible to handle various line delimiters
for splitting lines in a String.

Discussion was lengthy in trunk about whether or not these various
line delimiters should have made their path inside the image.
Some would prefer to stick to simple st-80 cr-only handling in image
and carry ALL the conversions at read/write to the complex external
world.
The rationale is that complexity should not enter the image.

My POV differs.

1) because handling cr-lf-crlf in image is not that complex (judge how
complex is the new code versus the old one)
2) because it is not CPU intensive (The line splitting methods were
not optimized, thus I reduced the cost of splitting, and therefore, I
reject the argument that it does matter that much)
3) because making the right decision about conversion can depend on
applications and can be complex, that's why it should ultimately be in
the hands of programmer.

I see no contradiction in using detectLineEndConventions in Pharo tools.
Though the current algorithm fail to handle mixed-conventions files
correctly, that's a good default policy.
But this simple trick can NOT handle ALL the cases (the
mixed-conventions is an example).

A universal line end converter fitting all possible use cases does not
exist and would be more than complex.
Let the grown up programmer decide what better fits his application
and provide decent tools to him (her).

If you decide to reject these modifications, then please revert
http://code.google.com/p/pharo/issues/detail?id=1356 for consistency.

cheers

Nicolas


> On Nov 20, 2009, at 6:09 PM, Philippe Marschall wrote:
>
>> Stéphane Ducasse wrote:
>>> Hi nicolas
>>>
>>> I was dicussing today with juan vuletich about the management of end of 
>>> line convention and I think that
>>> he is right. When we edit a file we should be in control about that we want 
>>> to have.
>>> In CUIS when you edit a file you can decide the convention or change it.
>>> He told me that in the squeak world people were pushing that the end of 
>>> line is controlled by the platform.
>>> My point of view on this is :
>>>      - when I manipulate the text object may be we should have the platform 
>>> convention.
>>>      - when I edit a file I should get the control because I may want to 
>>> edit a file on mac with unix convention.
>>>
>>> So nicolas I saw that you pushed a slice about fixing end of line.
>>> What is the design behind it?
>>
>> End of line convention in which context? The changes file? File outs?
>> File streams?
>>
>> Cheers
>> Philippe
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to