Thanks It makes sense to me. I like to have a good default and give the power to the programmer.
Stef On Nov 20, 2009, at 7:39 PM, Nicolas Cellier wrote: > 2009/11/20 Stéphane Ducasse <stephane.duca...@inria.fr>: >> 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 >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
