Extending FileList with CrLf

Daniel Vainsencher danielv at netvision.net.il
Sat Aug 2 09:33:29 UTC 2003


Yup. Here is my proposal.
1. People want to see flexible line endings in the FileList. Make file
list use CrLfFileStream explicitly, adding some appropriate protocol to
FileDirectory (#smartFileNamed: or some such). Consider adding a bit of
state to FileList so that files can be saved either with their original,
remembered line convention, or the default line convention (see next
point). Rename CrLfFileStream (since now all file streams can use any
convention) to SmartFileStream, or some such. Remove the concreteStream
indirection, so that the protocol used determines precisely what stream
class is used. This makes it easy to give people examples that will
magically work regardless of platform convention by using that
interface.
2. Some people want their local OS to determine the default line end
convention. Move the support for detecting and using the os line
convention down into FileStream. Vote on whether it should use OS or
Squeak convention by default.
3. We can either determine that .st,.cs files are defined to use crs to
maintain backward compatibility and squeak-wide compatibility. I'm
curious if any standard defines this about the format. Anyway, we decide
this on a per format basis, and adapt the code to use the appropriate
filestreams and modes.

Benefits?
1. People get the behavior they want in various applications.
2. The abstractions of "line ending" and "le auto detection" become more
separate, so that it is easier for programmer to actually get the
behavior they want for their programs.
3. We have the option of getting the precise and common abstraction
almost everybody else is using of OS specified, consistent line endings,
which seems to cause minimal confusion.
4. The CrLfFileStream behavior becomes bound to a specific interface
defined on FileDirectory, so that it is neither more nor less visible
than StandardFileStream.

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> > If I misunderstand this discussion and am talking at a tangent out of 
> > ignorance please forgive me.
> 
> No, you are restating precisely the arguments that numerous people have made
> by now. And Daniel is restating precisely the arguments he has made in this
> thread all along. It's almost funny.
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: squeak-dev-bounces at lists.squeakfoundation.org 
> > [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> > Behalf Of Jimmie Houchin
> > Sent: Friday, August 01, 2003 11:26 PM
> > To: The general-purpose Squeak developers list
> > Subject: Re: Extending FileList with CrLf
> > 
> > 
> > Daniel Vainsencher wrote:
> > > Jimmie Houchin <jhouchin at texoma.net> wrote:
> > > 
> > >>Just for other outside information. Apparently the Python 
> > group has been 
> > >>struggling with this issue. I normally don't read about Python, but 
> > >>occasionally take a peek. :)
> > >>
> > >>This PEP has been implemented and is in the latest Python.
> > >>
> > >>http://www.python.org/dev/doc/devel/whatsnew/node7.html
> > > 
> > > Note that they implemented the library so it requires an explicit
> > > parameter for it to enter "universal" mode. That is exactly what I'm
> > > proposing we do. This is not what CLFS does.
> > 
> > That may be so. But were not Python. :)
> > Python also has no environment per se.
> > Python is a language. Squeak is more.
> > 
> > >>Talks about the problem and how they decided to handle it 
> > for Python.
> > >>
> > >>Personally, I'm for handling it as elegantly and transparently as 
> > >>possible. I think that is what most people will expect. I 
> > understand 
> > >>Daniel's position. However, Squeak is a high-level environment. 
> > > 
> > > I don't know what a "high level environment" is. Squeak 
> > applications are
> > > able to provide convinient application level abstractions 
> > because they
> > > build on rich lower level abstractions in the class library. I am
> > > stating that the two abstractions "line ending" and "auto 
> > detect line
> > > ending" should remain separate, so that different 
> > applications can each
> > > use what it requires.
> > 
> > Now Daniel.
> > Squeak is more than a language.
> > Squeak is more than the sum of its libraries.
> > 
> > Most of us here are consumers of some software written in Squeak.
> > You can do many things in Squeak as a user without ever 
> > writing a single 
> > script or line of code.
> > 
> > When I open the World menu and click on file or file list, I 
> > am a user 
> > of the environment or that specific application. When I view files on 
> > Linux it doesn't render line endings correctly. I can't speak 
> > about Windows.
> > 
> > I imagine this goes back to the default behaviour of Squeak.
> > This is a part of the user experience. It seems to me this is 
> > what most 
> > are wanting to be different.
> > 
> > As a programmer, feel free to choose the behaviour you want.
> > 
> > >>Low-level options are there, but I believe most people 
> > expect intuitive 
> > >>responses. I don't expect to open a text document written on the 
> > >>platform I'm using Squeak on and Squeak not handle it properly.
> > > 
> > > We could change the default to be OS line endings - this is 
> > a reasonable
> > > change. If you want your text editor to handle any strange 
> > line endings,
> > > change your text editor to use an "autodetect line endings" 
> > mechanism.
> > 
> > Why on earth would anybody not want their text editor to handle line 
> > endings correctly? If the text editor has the ability to 
> > understand what 
> > is meant, it should be the very reasonable responsibility of the text 
> > editor to do the right thing. Why would I want my text editor 
> > to create 
> > visual garbage merely to demonstrate that some of the line 
> > endings came 
> > from a different platform? So I could manually enter into the 
> > text and 
> > delete them and enter correct line endings. Yuck.
> > 
> > > However, the default should remain a clean "line ending" 
> > abstraction,
> > > without autodetection as it is in Python, C and probably most other
> > > general purpose languages.
> > 
> > But Daniel. We chose _not_ to use those other languages. Part 
> > of which 
> > is having better (possibly higher) abstractions. (even as default)
> > 
> > You talk about libraries, applications and defaults. Its a 
> > bad default 
> > for libraries, but good as a default for applications. Squeak _is_ an 
> > application. Squeak _is_ an environment. Squeak _has_ a language.
> > 
> > I think Squeak should improve on the status of programming.
> > 
> > As long as we have to interface and communicate with the 
> > world outside 
> > Squeak, including text files, I think we should do it elegantly.
> > 
> > Changing a default behaviour in Squeak doesn't remove your or 
> > anybody's 
> > ability to use the lower level library. Okay, we can say it merely 
> > changes were the pain is felt. Since the computing world is not 
> > consistent in many areas there is some pain. This is pain management. 
> > Maybe we (I) believe that this reduces the pain in the common usage.
> > 
> > I have battled the default behaviour while parsing files. I 
> > expected one 
> > thing got another. In the end I chalked it up to my Squeak learning 
> > curve. But I feel I am not alone in my pain.
> > 
> > If I misunderstand this discussion and am talking at a tangent out of 
> > ignorance please forgive me.
> > 
> > Well anyway, I'm over my 2 cents.
> > 
> > Jimmie Houchin
> > 
> >



More information about the Squeak-dev mailing list