Hi,

In message "[ruby-talk:9540] Re: reading an entire file as a string"
    on 01/01/19, "Aristarkh A Zagorodnikov" <xm / w3d.ru> writes:

|Another holy war for code good look and it's clarity:
|What of presented methods are better ... _and_ why ?
|
|1. buff = File.open("/etc/hosts") {|f| f.read() }
|2. File.open("/etc/hosts") {|f| buff = f.read() }
|3. buff = File.new("filename").read(nil)

I think it's mostly up to preference.  I prefer 3, because it tells me
what it's doing most directly, although it leaves open file unclosed.
That's the reason I considered adding

 4. buff = File.read("/etc/hosts")

|P.S. I am really interested. There are many such "many-ways-to-do-it" in
|Ruby ... i.e. 'for' as another form of 'each' iterator, etc. I need answer
|to my question to make a more formalized language for use within our company
|(and not only - will be public domain). It will be more ... restricted, I
|think. Ruby now suffers sometimes from legacy stuff, even though being the
|most clear language I've seen. I'd like to reform some language constructs
|and eleminate/reconstruct some object methods, etc.

It's good news to hear.  Stay in touch about your language.
But remember, small is not always beautiful, big neither.
It's a matter of balance.

This is why I'm in good relation with Larry Wall even though we made
different decisions.  We both know it's a game of balance.

|P.P.S. Also - thanks to Matz ... The thing which impressed me mostly was not
|syntax, not OO, not good objects ... it was GC ... though it is clear from
|the license that some of GC code is not yours - Ruby seem to have one of the
|most wonderful memory managers with GC.

It relies heavily on its forerunner, siod, scm, etc.  And it will be
more wonderful using generational scheme in near future.  Stay tuned.

							matz.