On Sun, 6 Feb 2005 06:49:03 +0900, Esteban Manchado VeláÛquez <zoso / foton.es> wrote: > On Sat, Feb 05, 2005 at 10:29:11AM +0900, James Britt wrote: >> Esteban Manchado VeláÛquez wrote: >>> And, w.r.t. the reply from James Britt, he said: >>>> Sad, but unless you are paying someone you shouldn't expect >>>> developers to be too concerned with writing new code that runs >>>> on older versions of Ruby. (And I expect this is true in most >>>> developer communities, so nothing scary about Ruby in this >>>> regard.) >>> Yes, you're right, you can't "expect" developers to do that, but >>> I think Ruby would gain acceptance if more developers tried to >>> remain compatible. >> That's, um, crazy. Writing new code and checking that it runs in >> both 1.6 and 1.8? Then you're basically writing to 1.6. > Yes, that is what I mean. Are there really so much performance- > boosting features in Ruby 1.8 (the language; I guess the libraries > should be easy to upgrade.... if they work in Ruby 1.6) that going > to 1.6 for _some_ important libraries sound crazy? It not telling > everyone to not use new lenguage features (sorry if it sounded > like that), I'm simply saying that keeping some important > libraries/applications compatible with Ruby 1.6 would probably > make Ruby stronger in the eyes of many bussinesses. Yes. One of the main features in Ruby 1.8 over 1.6 was the following: h = Hash.new { |h, k| h[k] = [] } h[:one] << two Before this feature, a lot of code would have had to look like: ((h ||= {})[:one] ||= []) << :two Possibly on split lines, but the behaviour is far more easy to manage now. Also, the library differences are important because they *do* behave differently and there are *more* of them. In many ways, I think that the Ruby 1.6 -> 1.8 upgrade is closer to Perl 4 -> 5 (or perhaps the numbering from Perl 5.005 -> Perl 5.6) than a smaller upgrade. Matz has ambitious goals for Ruby 2.0 which limit the version numbering. -austin -- Austin Ziegler * halostatue / gmail.com * Alternate: austin / halostatue.ca