RubyistMagazineVol8 #
Rubyist Magazine vol.8 (a Japanese web magazine) has been published. Although I can not introduce whole the articles, a long and deep iterview to Akira Tanaka, a.k.a akr, is very interesting because I can feel the origin of his way.
Ruby and easy-to-use libraries made him change his mind. Until meeting Ruby he used to think that program did or did not work in an academic way, which was a kind of dualism. However, Ruby seemed to be optimized for ease-to-use and there should be something just more than available: very easy and simple to use, hard to make it work or almost unable to run and extend. Then he deliberates interfaces of Ruby libraries. He is afraid that some non-core libraries might not be so mature as Matz or akr are satisfied with.
He told an idea to introduce a literal for pathname
rather than Pathname.new
. pathname should be handled as an object as easily as possible. I will vote yes.
Tip: as of Ruby 1.8.2 you can write URI("http://jp.rubyist.net/").read
instead of open("http://jp.rubyist.net/").read
. GC does not need to close in the URI
style (I don’t know what this means).
MenTaLguY
URI("http://jp.rubyist.net/")
returns aURI::HTTP
, whereasopen("http://jp.rubyist.net/")
returns aStringIO
.URI::HTTP#read
opens and closes a stream internally, whereasStringIO#read
only performs a read on the existing stream and leaves the stream open (until it is reaped by the GC).However, I’m not sure what additional resources (if any) could be freed by closing a
StringIO
, so it may not matter much either way.why
I’m a big akr fan and his picture is now my desktop wallpaper.
Daniel Berger
“He told an idea to introduce a literal for pathname rather than Pathname.new. pathname should be handled as an object as easily as possible. I will vote yes.”
I will vote no.
gammarian
I will abstain.
grammarian
Then I will spell my own name correctly.
MenTaLguY
Hmm, I’ve got mixed feelings about pathname literals. I guess I’ll vote no. I don’t think it needs to be.
But it would be nice if it were even more visible in the standard library and so forth somehow…
why
Literals make better sense with multi-line strings, but I guess you can still just pass them in as a braced string to a method:
I despise quotes around multi-line strings—that dangling quote. So literals are nice cause they mark open and close. But I also think it’s handy because (visually) you’re reserving a string type. The possibility for providing other data-describing annotations in Ruby increases by giving it its own syntax hook.
In fact, it would be really cool if we could capture the symbol used to surround the literal. So to build a JSON array:
Maybe I’ll join the quotes side if we can get some Unicode curly quotes around our strings.
Daniel Berger
“Literals make better sense with multi-line strings”.
No, they don’t. Quotes and HERE documents are quite sufficient, and they make sense. I’m not sure why having strings wrapped with “{}” or “[]” versus quotation marks gives you the warm fuzzies, but we don’t need it, and it doesn’t make it any more readable.
Stop trying to program in YAML .
MrCode
What about when you have a string full of quotes?
Maybe it doesn’t happen that often, but I’d rather have the choice than not.
Daniel Berger
Just thought I’d mention there’s already an RCR for this (#279) if folks here wish to vote for or against.
Comments are closed for this entry.