До сих пор я просто использовал YARV (ruby 1.9) как просто более быструю реализацию ruby, чем ruby 1.8, и гарантировал, что весь мой код обратно совместим с ruby 1.8.6. Какие обстоятельства, если таковые имеются, мешают вам писать 1,9-специфический код?Что мешает вам писать Ruby 1,9-специфический код?
Одна причина за ответ.
Также, если речь идет о рельсах, то проблема заключается в совместимости драгоценных камней/плагинов с ruby 1.9. Я уверен, что каждый, кто хочет перейти на 1.9, следит за
isitruby19.com
Я хотел бы forget about Iconv при обработке данных Юникода, например:
Iconv.conv("utf-8", "utf-16le", blob).split("\n")
, но до сих пор я не мог найти хорошие примеры/учебник 1.9 юникода обработки еще.
Во многих операционных системах легче установить ruby 1.8, чем ruby 1.9.
Если вы пишете драгоценный камень/библиотеку, вы не знаете, какую платформу используют ваши пользователи. (Интересно, посмотрим ли мы когда-нибудь на isitruby18.com?) –
Если ответ «не знаю, какая платформа» был убедителен, нам все равно нужно было бы настроить таргетинг на Ruby 1.6 или ранее, и никаких новых функций на этом языке не было бы _ever_ будет использоваться. – SFEley
Когда люди переключались с 1.6 на 1.8, и как люди тогда обрабатывали вещи?Или это не проблема, потому что люди не писали драгоценные камни? –
Первый выпуск для Ruby 1.9.2 должен состояться в конце мая, и я считаю, что многие ждут 1.9.2 до прыжка на поезде 1.9.
Не совсем ответ на ваш вопрос, но для начала написания кода использует 1.9.2 методы, вы можете require "backports", и большинство функций будет доступно вам, даже в Ruby 1.8.6 (хотя и не так быстро, курс).
Я не знаю, Руби так хорошо, чтобы отличить 1.8 от 1.9 (ну это моя причина: P)
Ничто не обескураживает меня. Я использую Ruby 1.9.1 для всего, что я делаю в течение почти года, и у меня было мало проблем. Мой majorgemsтребует 1.9 по разным причинам (легкий UTF-8, волокна и т. Д.), И я не испытывал никаких сомнений по этому поводу. Для некоторых других камней trivial я мог бы сделать токен, чтобы сохранить их совместимыми с 1.8, что в основном означает не использование синтаксиса чистого синтаксиса.
1,9 - текущий рубин. Я вижу, что нужно сохранить старый Ruby для устаревшего кода, который не стоит обновлять, или предпочитая альтернативный Ruby (JRuby, Rubinius и т. Д.), Но это действительно меня озадачивает, почему так много людей все еще начинают новые проекты в более медленной, устаревшей Ruby 1.8.x линии.
Я нашел это просветительское: http://blog.grayproductions.net/articles/understanding_m17n – steenslag
@steenslag, спасибо за ссылку – ohho
Вот еще лучший вариант: http://yehudakatz.com/2010/05/05/ ruby-1-9-encodings-a-primer-and-the-solution-for-rails/ – SFEley