From: matz@... (Yukihiro Matsumoto) Date: 2001-01-19T16:01:30+09:00 Subject: [ruby-talk:9542] Re: reading an entire file as a string Hi, In message "[ruby-talk:9540] Re: reading an entire file as a string" on 01/01/19, "Aristarkh A Zagorodnikov" 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.