Re: [gobo-eiffel-develop] Handling end of line stuff.

[Christian C. <chc...@cl...>]

Greg C wrote :
> 
> Here are my thoughts.
> 
> The OS-specific EOL convention can be placed in a constant string, which
> is then used to match the actual EOL. Runtime interfaces can then be used
> to select a specific convention.
> 
> for example (warning untested code follows):
>    .
>    .
>    .
> feature {ANY}
>    eol : STRING
>    unix_eol : STRING is "%N"
>    ms_eol : STRING is "%R%N"
>    mac_eol : STRING is "%R"

I fully agree with this.

Sometimes ago I posted such a proposal on a NICE list because I think
it's much better and easier to write something like :

io.put-string("Hello world !" + eol)

than 

io.put_string("Hello world !%N")

or

io.put_string("Hello world !")
io.put_new_line()

I think that %N and %R are C like stuff that should not be used in high
level programming. They are also very disturbing because you don't know
if your program will be portable to Windows or other platforms if you
use an hardcoded "%N".

And put_new_line like features are awfull too because it means that
every time you add a "put_string" or an "append_string" like feature to
a class you should also add a special case "put_new_line" or
"append_new_line" feature to the class. 
It's also much shorter to type " + eol" than "io.put_new_line" on a new
line or something like this.

So I think that not having a standard new line feature (called "eol" or
"nl") is a very bad design mistake in Eiffel.
And it strikes you as soon as the "hello world" program... 

My opinion is that GOBO should have such a feature used everywhere
instead of "%N" and "%R".

> feature make is do eol := ms_eol end -- set a default
> 
> set_unix_conventions is do eol := unix_eol end
> 
> -- and so forth.
> 
> The line reading code could even be adaptive, setting the EOL type the
> first time it encounters one.
> 
> Note that you don't want to do this "once" since a program could easily
> have to process files with different conventions at the same time.

If it's not a once feature, then it means each object has a memory
overhead, except if we accept to write something like "io.eol" instead
of "eol".
Solution to this problem is perhaps to undefine or redefine an inherited
eof feature from ANY in the FILE or IO class used to process files with
different conventions.
There are probably expert people knowing Eiffel much better than me who
could tell how to do it (if possible).

Regards,
Christian.