Обновить
34
0

Пользователь

Отправить сообщение

Как они умрут вместе с классом? @protocols — инстанс переменная BlackTie, которая не очищается при релоаде никак сейчас. Ну и это не WeakMap чтобы автоматически чистить старые ключи.

$ rails c
2.3.0 (main):0[1] > User.hash
=> 518965653690491956
2.3.0 (main):0[2] > reload!
Reloading...
=> true
2.3.0 (main):0[3] > User.hash
=> -3861495400228448213

Не будет эксепшена. А утечка будет.

А зачем такое писать? Как это в реальной жизни пригодится?


зато можем прикрутить к нему аспект, например. Поставить точку останова. Отладить. Да что угодно.

Что? А обычные брэйкпоинты на строчках уже не модные? Как вы будете отлаживать код, где (о ужас) нет Proc.new? Про аспект вообще впервые слышу. Ну да, нам среднестатистическим рубистам это только предстоит постичь (или даже не предстоит).

Представьте себе протокол Tax (налог). Он можен быть определен для таких классов, как ItemToSell, Shipment, Employee, Lunch и так далее.

Вот только для товаров — это ндс, для сотрудников — ндфл, для доставки — я не знаю, и уж тем более не понимаю, какое отношение к остальным имеют обеды. И как все эти объекты связаны между собой.

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

2.3.0 :003 > def x(&block); [block.class, block.object_id]; end; x {}
 => [Proc, 70195284674480]

Это разве не объект? Что с ним нельзя сделать такого, что можно с Proc.new. Код приведите, пожалуйста.

Я знаю, что yield быстрее: https://github.com/JuanitoFatas/fast-ruby#proccall-and-block-arguments-vs-yieldcode


В этом то и плохо: вы оптимизируете там, где оптимизация не нужна в принципе:


  • Рядом циклы, куча других тяжелых инструкций.
  • Протоколы будут создаваться только во время загрузки приложения, и их вряд ли будет больше 1000.
  • Proc.new создает объект на стеке. Насколько такая связка быстрее (или уже медленнее?) чем явный &block.
  • По ссылке видно, что там миллионы оп/с. Это экономия сотен пикосекунд! Сравните это со временем, потраченным в кейсе на 4 строки, в нём 2..4 вызова метода. Он к тому же выполняется не только на этапе загрузки.

Упс
Warming up --------------------------------------
            proc_new    79.098k i/100ms
           and_block    82.507k i/100ms
Calculating -------------------------------------
            proc_new      1.220M (± 5.6%) i/s -      6.091M in   5.008569s
           and_block      1.395M (± 4.5%) i/s -      7.013M in   5.038238s

Comparison:
           and_block:  1394884.4 i/s
            proc_new:  1220305.9 i/s - 1.14x  slower

require 'benchmark/ips'

def target
  yield
end

def proc_new
  target &Proc.new
end

def and_block(&block)
  target(&block)
end

Benchmark.ips do |x|
  x.report(:proc_new) { proc_new { 1 + 1 } }
  x.report(:and_block) { and_block { 1 + 1 } }
  x.compare!
end

Но, несмотря на всё это и жертвуя читаемостью, вы гонитесь за уменьшениям количества объектов на стеке. Без объяснений в статье или в переводе. Так же без объяснений бы советуете читать код, того ненужного case. Сейчас говорите про наследия 1.9, но весь код для 2+.


Итого. блестящий пример внятного DSL, который учит:


  • Отключать рубокоп, чтобы писать большие, сложные для понимания методы.
  • Использовать неуместную оптимизацию. Которая оказывается деоптимизацией.
  • Не думать об утечках памяти.
  • Писать индусский код (вроде так называется этот case. Индусы писали больше строк, чтобы заработать больше денег).



Про юникод в коде. Многи сейчас стремятся, чтобы большее число людей могло заниматься разработкой. В том числе и люди с ограниченными возможностями. Ладно, я могу "настроить себе клавиатуру". (Что если я буду работать не со своего компьютера? На другой ОС? Что если с планшета? Что если я буду править его в консоли без поддержки юникод? Почему я вообще должен настраивать свою клавиатуру, если лиду/сто просто так больше нравится?!). Но я не уверен, насколько легко это будет всем остальным.

  1. Действительно, был не прав. Не учёл, что def могут идти в перемешку с дсл.
  2. Я честно пытался, ничего не нашёл. Пробовал сравнивать caller внутри блока с &block и Proc.new — одинаковые. Расскажите, пожалуйста, в чём отличие.
  3. https://github.com/printercu/dry-behaviour/commit/046163b3216f884d2bc7dee757cfac15e7b1f341 Ок, был неправ, по-другому: this.send(target, *args, &λ). Тесты проходят.

Долго сдерживал себя от написания критичного комментария, но аргументов всё больше а понимания всё меньше.


  1. Вообще говоря, взяться за перевод меня побудило то, что эта имплементация (даже не так важно, чего именно) — блестящий пример внятного DSL

    Методы по 20+ строк — это не блестящий пример. Ни капли объяснения. Объяснили бы зачем хотя бы сохраняются params в defmethod?


  2. потому что MRI уже сейчас — нонсенс

    Если такие протоколы в продакшене использовать, то остается только догадываться, насколько оптимален код в остальном.


    Про реализацию немного.


  3. ims = instance_methods(false)
    class_eval(&Proc.new)
    (instance_methods(false) - ims).each { |m| class_eval { module_function m } }

    Вместо всего этого достаточно singleton_class.class_eval.


  4. class_eval(&Proc.new)

    Запрет на &block? Или "потому что могу!".


  5. https://github.com/am-kantox/dry-behaviour/blob/master/lib/dry/behaviour/black_tie.rb#L50-L55 всё заменяется this.send(target, *args, **params, &λ). (Сюда же: что О_о??? потому что могу!)
  6. Память то течёт в рельсах в девелопменте. Ах да, они же не труЪ. Этот пункт тогда можно не считать, пусть мучаются.
  7. ...

Конечно, если автор руби не знает достаточно хорошо, он и будет сочинять такие библиотеки. Ведь всё запросто решается созданием нескольких модулей. Я допускаю, что такие протоколы могут найти применение в руби, но не могу представить себе и единственного варианта (автор нам не даёт и подсказки, как их применять в жизни).


Зачем окружающим такой код показывать, тем более с целью научить писать дсл. Я считаю, что такие статьи вредные.


PS. В питоне в инстанс методы, передают первым аргументом сам инстанс. Говорят, это очень явно и всем нравится. Ждём dry-explicit. Потом dry-decorators (для методов, не объектов).


PPS. До сих пор в догадках теряюсь, кто плюсует такую статью. На гитхабе у репа ни звезды. Друзья?! Накрутка?!

Пришлось тут связаться с mysql, после уже долгой работы с postgresql. Как же я рад, что постгре "не саблюдает" стандарт, и DDL тоже транзакционно выполняет. Очень не удобно откатывать половину миграции, если 2я половина дала сбой.


И case-sensitivity тоже радует.

ИМО, лучше как можно раньше перейти с ____-__-__ на \d{3}-\d{2}-\d{2} (или хотя бы {3}-{2}-{2}), чтобы потом меньше переделывать и не считать курсором подчеркивания. При том что парсер можно сразу не делать навороченым, а поддерживать только небольшую грамматику.

И rsing забавно %)

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

Подумалось вот, есть ли корреляция соотношения полов жертв и/или убийц с соотношением полов в местности.

Посоветуйте, пожалуйста, что почитать, чтобы подробнее узнать.

Про long shadow расскажите немного подробнее, пожалуйста. Как я понял по гуглу, это стиль с тянущейся до конца экрана тенью, который в свое время эппл применил в своих иконках, а потом и все подряд. На скриншотах этого я не увидел. И не совсем понимаю, как он "дает наиболее полное представление об элементах управления и навигации...".

Было много выпадов на него? Вроде всем понравилось, как я понял.

Я особо не слежу, но мне не попадается уже пару лет про пхп ничего нового такого. Про го — помню, про ноду — помню, про скалу — тоже. Про пхп — нет, уже все давно написано. Да и выпадов на пхп, по-моему, меньше стало.

Откуда такой кипиш?! Раз в месяц кто-то новый пишет, как ему не нравятся рельсы. Ну не нравятся — хорошо. "Но, пожалуйста, не доставайте и не размахивайте им на людях."

Упс, спасибо! Гугловый автокомплит только подкрепил мою ошибку :(

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность