Обнаружена критическая уязвимость в Ruby on Rails

я имею в виду стабильную версию redmine.

последняя стабильная версия вышла в середине декабря, правильно? на тот момент там

gem 'rails', '3.2.8'

получается, что все стабильные установки redmine сейчас подвержены опасности, правильно?

Скажи, а как так получается, что для того чтобы Redmine начал работать с новым Rails, нужно скачать новую версию первого?

в том же js за расширение прототипов надо бить больно

чтоооо за бред.. как хочу прототип, так и создаю.

Создавать создавай, а вот расширять где попало не стоит.

манкипатчить классы можно и в пайтоне, вот только делать этого не стоит.

а ты в gemfile пробовал исправить? Удалить gemfile.lock,

bundle install

манкипатчить классы можно и в пайтоне, вот только делать этого не стоит

Я даже знаю почему.. Я даже знаю несколько причин)) И я бы даже сказал, что нельзя.

чтоооо за бред.. как хочу прототип, так и создаю.

Да классная логика, напишу рид-онли код, который невесть как работает, а пусть потомки разгребают. Молодец, долго жить будешь.

Ты же, можешь не использовать, если не хочешь. Никто не против.

Ну если не хотеть, то надо вообще от руби отказываться. Никто же не пишет на голом руби, у него есть инфраструктура, библиотеки. И вся эта инфраструктура «магическая», в которой один реквайр может поменять поведение чего угодно, вплоть до основных типов. Кому нравится - пусть использует, конечно, я ж не могу запретить.

В питоне тоже можно заманкипатчить все очень сильно, даже встречал продукты, где просто капец как тяжело понять, что и откуда взялось (например, в zope2). Но к счастью такой подход не часто встречается, и большинство разработчиков библиотек и фреймворков следуют принципу «explicit is better than implicit». В руби наоборот. Это философское расхождение, кому что нравится.

а ты в gemfile пробовал исправить?

зачем? почему я должен лезть в их исходный код?

bundle install

я в курсе об этом, спасибо

Не путай теплое с мягким говорю тебе. Философское расхождение может быть в голове, а возможности языка в интерпретаторе. Чем хуже и беднее язык, тем лучше чтоли.

Я даже знаю почему..

Давай, поделись.

Чем хуже и беднее язык, тем лучше чтоли.

Разумные ограничения всегда вполне уместны. Строгая типизация - это тоже ограничение, например.

Lol. Хоть и люблю ruby, но ты упёртый.

Разумные ограничения всегда вполне уместны

Не надо этого самообмана.

Скажи, как ты будешь обеспечивать модульность приложения. Существующий функционал класса не сможет всегда тебя устраивать и тебе потребуется его изменить, и какой у тебя вариант кроме monkey patch? На самом деле это в питоне будет монкейпатч, а в руби это нормальная и красивая конструкция (благодаря пространству имен и конструкциям include, extend и hook-методу included).

Потому что объекты не обновляются, потому что нет специальных конструкций для этого. Короче говоря, потому что это неудобно.

Почитай уже Data model, а?

Существующий функционал класса не сможет всегда тебя устраивать и тебе потребуется его изменить, и какой у тебя вариант кроме monkey patch?

Обычно это решают наследованием.

Чем хуже, тем лучше

Так на асме надо писать - самое оно. К чему эти абстракции. Все же так неявно..

Если приложение использует класс A, как ты заставишь его использовать свой класс?

Никак, потому что не привык стрелять себе в ногу.

Хотя вообще-то это возможно... =) но только в крайних случаях так делают.

Расскажу, пожалуй: приходилось мне манкипатчить модуль datetime, чтобы ускорить время для тестового инстанса одного сервиса, который тестировать с настоящим временем сильно долго. Всё получилось, внезапно.

Егор снова сломал жыдхаб?

Всё получилось, внезапно.

Я рад, но в чем профит от этой внезапной объектной модели. Когда нужно перечислять методы, чтобы их наследовать и еще куча внезапных вещей. Помоему автор поиздевался над вами.

MIT

Руби это MIT во все поля, но, вы хотите сказать, что питон это «Worse is Better»?) - нет. Какая-то нелепая неудобная модель. Руби может все то же, но в нем есть и лучшие конструкции.

Я правильно понял, что теперь неймспейсы в питоне есть?

Как менять поведение класса без наследования найди теперь сам. Но не вздумай так делать. Ты хоть понимаешь, что люди пишущие код, где «один require в середине файла полностью меняет поведение» системы чаще многих других становятся жертвами бытовых убийств?

Существующий функционал класса не сможет всегда тебя устраивать и тебе потребуется его изменить, и какой у тебя вариант кроме monkey patch?

В 99% случаев вопрос решается наследованием. В оставшихся - делается обычный патч.

Я правильно понял, что теперь неймспейсы в питоне есть?

Под неймспейсами я понимаю A::B::C::D, где это в питоне есть? Где в питоне

class A
  include M1
  include M2
end
class B
  include M1
  include M2
end

один require в середине файла

В руби есть gemfile для этого. И суть не в том чтобы поменять функционал, а в том, чтобы без труда подключить функционал к приложению.

В 99% случаев вопрос решается наследованием Как тебе наследование поможет тебе изменить существующий класс?

В оставшихся - делается обычный патч.

Какой еще «обычный патч».. Делается костыль. Отюда возникает вопрос, зачем делать костыли, когда есть язык с нормальными конструкциями?

Где в питоне

Множественное наследование, тебе уже 10 раз сказали. Твои include в руби - это костыль, который ввели из-за того, что Матцу было влом реализовывать множественное наследование.

Как тебе наследование поможет тебе изменить существующий класс?

Получаешь новый класс, с нужным тебе функционалом. Фишка здесь в том, что ты всегда видишь перед собой полное определение класса. В руби же определение класса размазано по куче файлов, и добавление любой новой библиотеки может его еще раз поменять. Если ты не понимаешь, в чем проблемность такого подхода, то я уже даже не знаю, что говорить.

Какой еще «обычный патч».. Делается костыль.

Такой себе обычный. Берешь исходник, правишь код, делаешь diff. Можно потом даже в апстрим отправить. Универсально для любого ЯП.

Так это в питоне делается множественным наследованием. Пространства имен тут не при чём.

Наследование, это наследование. И наследование, кстати, критикуют все кому не лень. В руби есть пространства создаваемые модулями, в питоне нет таких пространств.

И наследование, кстати, критикуют все кому не лень.

Есть определенные сложности с mro, да. Но они не сравнятся с хаосом открытых классов. :)

в питоне нет таких пространств.

Так как есть другие вещи, которые выполняют функционал рубиевских костылей человеческими методами.

с нужным тебе функционалом

и ненужным

В руби же определение класса размазано по куче файлов

Ты чтоли в один файл весь свой код херачишь. Бестолочь, это плюс, а не минус: пространство имен не связано с файлами. С чего вы решили, что оно вообще должно быть связано.

Так как есть другие вещи

Ну покажи, или это какой-то секрет питонистов.

Но они не сравнятся с хаосом открытых классов.

Ч_Ч в питоне классы тоже открытые! Никто не запрещает тебе их переопределять, ты о чем вообще. И это опять же плюс. Иначе надо использовать другие языки.

Не матерись, потрут.

и ненужным

Поясни.

Ты чтоли в один файл весь свой код

Нет. Просто питон по традиционной человечекой логике требует хранить определение каждой сущности в одном месте.

С чего вы решили, что оно вообще должно быть связано.

Потому, что так можно быстрее разобраться в незнакомом коде. Вижу вызов функции какого-то модуля, я сразу знаю куда идти смотреть ее исходник. А в руби как? Грепать файлы всех подключенных модулей?

Ч_Ч в питоне классы тоже открытые!

Нет, переопределение класса в питоне создает новый класс, при этом старый становится недоступным. В руби же нет переопределения, каждая запись class foo прото добавляет методы в существующий класс. Это огромная разница.

Грепать файлы всех подключенных модулей?

Разные способы есть, например документация. Но у тебя гораздо большая проблема, ты вынужден изменять файл (например стандартной библиотеки).

наверное он о том, что можно назначать новые методы в инстанце класса

Таак.. и как тогда в питоне делать монкипатч?

Но у тебя гораздо большая проблема, ты вынужден изменять файл (например стандартной библиотеки).

Нет, стандартная библиотека на то и стандартная, чтоб быть везде одинаковой.

А то, что в одном рубиевском проекта одна стандартная библиотека, а в другом немного другая стандартная библиотека - я иначе как хаосом не могу назвать.

Разные способы есть, например документация.

Шикарно, чтоб понять, как работает тот или иной метод стандартной библиотеки мне нужно перелопачивать документацию (или сорцы) всех используемых библиотек. При этом, если пока я отходил пить чай, другой девелопер добавил еще какую-то библиотеку, то поведение опять могло поменяться. Это ли не хаос?

в питоне просто не делают таких глупостей, из-за которых нужно прибегать к таким действиям

Поясни.

Ну так, я изменил функционал класса и часть методов теперь мне не нужна. А в последствии я изменил класс так, что он вообще уже не похож на изначальный. Сам факт того, что нужно что-то от чего-то наследовать - сомнителен.

Таак.. и как тогда в питоне делать монкипатч?

Как-то так - http://stackoverflow.com/questions/3765222/monkey-patch-python-class

А меня прикалывает упертость фанатиков-сектантов.

А в последствии я изменил класс так, что он вообще уже не похож на изначальный.

Ну так определи новый класс, если тебе нужно что-то совсем непохожее. У тебя очень зашоренный взгляд, для тебя существуют два подхода к программированию - такой, как в руби, и неправильный.

Множественное наследование, тебе уже 10 раз сказали. Твои include в руби - это костыль, который ввели из-за того, что Матцу было влом реализовывать множественное наследование.

Ты правда считаешь, что множественное наследование однозначно лучше примесей? Не говори об этом громко, засмеют.

Как-то так - http://stackoverflow.com/questions/3765222/monkey-patch-python-class

ужос

Это ли не хаос

Вся жизнь хаос, что поделать. Я создаю программный интерфейс, который удобен мне здесь и сейчас, а не когда-то кому-то.

Да и не надо придумывать, что ты будешь наследовать django, чтобы что-то там чуть-чуть поменять? - нефига, откроешь исходник и перепишешь - и вот это реально плохо, потому что обновление больше не тривиальная задача.