A thing that I noticed in this post: some changes relate to "improper usage". Yes, Array#to_s did perform a join, but it was never the method intended to do a join - thats #join. This should never be done in the first place. Use the tools that are meant for the job, even if the other is more convenient (although I never understood this specific case, I always used #join). It will bite you if you don't. Another example was using #map without block as a #to_a alternative (which now returns an Enumerator).
Also, it shows that a lot of naming problems were actually corrected in the transition to 1.9, like the #type<>#class thing. Less is better and I am grateful that the core team actually made some cuts.
In the end, my personal experience is that upgrading to 1.9 is not that much pain as many say. Sure, for large projects, the work is substantial as an absolute value, but this sounded quite manageable. Sadly, their blogpost on their migration to Rails 3 doesn't mention any numbers in that regard:
Does anyone know why String.each was cut? String.each was one of the cool things that attracted me to ruby in the first place. I loved that you could say myString.each and it would assume you meant linebreaks unless you told it some other delimiter.
Strings were revamped in Ruby 1.9 to have more robust support of Unicode and other encodings. One of the side effects is that both the semantics and internal representation of Strings changed such that treating a String object as an Enumerable no longer made sense.
Working with Strings is so much better in post 1.8 ruby. Before it was hell with iconv especially for us guys who work primarily with non english languages.
The default splitter for split is newline:
"foo\nbar".split => ["foo", "bar"]
Now possible to get the individual letters as characters in a simple UTF safe way:
Yeah, but String#each_line was already present in Ruby 1.8, why didn't you use this in the first place? Much clearer meaning and still available. #each is pretty neutral.
Good post with some great details. I hope the holdouts on Ruby 1.8.7 REE look carefully at upgrading.
Rails 3.X is still a tough upgrade though. I'd be curious to see similar benchmarks with upgrading a large code base. I've heard a few stories of abandoned upgrades because of the slowness.
[+] [-] Argorak|14 years ago|reply
Also, it shows that a lot of naming problems were actually corrected in the transition to 1.9, like the #type<>#class thing. Less is better and I am grateful that the core team actually made some cuts.
In the end, my personal experience is that upgrading to 1.9 is not that much pain as many say. Sure, for large projects, the work is substantial as an absolute value, but this sounded quite manageable. Sadly, their blogpost on their migration to Rails 3 doesn't mention any numbers in that regard:
http://www.getharvest.com/blog/2011/01/harvest-is-running-ra...
[+] [-] techtalsky|14 years ago|reply
[+] [-] _pius|14 years ago|reply
There's a good treatment of this here:
http://blog.grayproductions.net/articles/ruby_19s_string
[+] [-] sunkencity|14 years ago|reply
The default splitter for split is newline:
Now possible to get the individual letters as characters in a simple UTF safe way: I like the stuff that has been done with enumerators, making it possible to map with index etc:[+] [-] Argorak|14 years ago|reply
[+] [-] hkarthik|14 years ago|reply
Rails 3.X is still a tough upgrade though. I'd be curious to see similar benchmarks with upgrading a large code base. I've heard a few stories of abandoned upgrades because of the slowness.
[+] [-] Argorak|14 years ago|reply
[+] [-] jhsu|14 years ago|reply