но зачем

итератор

ну сделай две строки

пришлось, но это повторение переменной, было бы круче в одну

@a = @a.to_i + 1

@a = @a.to_i + 1

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

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

cnt = 1.step { |i| break i if i == 5 } так можно вернуть счетчик без изменения переменных вообще

cnt = 1.step { |i| break i if i == 5 } так можно вернуть счетчик без изменения переменных вообще

мне итерировтать нужно в определённом месте с получением этого значения потом извне

так в cnt будет результат, можешь сделать @cnt =

так в cnt будет результат, можешь сделать @cnt =

class A < SuperA attr_reader :i def some_shit @i ||= 0 @i += 1 super end end a = A.new 3.times { a.some_shit } a.i #=> 3

да я ж не настаиваю)

не подходит, ну ладно

я бы только в конструкторе инициализировал бы переменные объекта

class A < SuperA attr_reader :i def some_shit @i ||= 0 @i += 1 super end end a = A.new 3.times { a.some_shit } a.i #=> 3

если дело происходит в рельсах то можно сделать self.increment!(:i)

точнее не везде в рельсах, это метод AR, если не путаю ничего

я бы только в конструкторе инициализировал бы переменные объекта

Сократил код для патчинга через наследование. Всё это в тестах просто

более правильный вариант не наследование, а композиция здесь

Что за "композиция"?

жесткая свяь между сущностями, где одна сущность является частью другой. Хотя это так себе объяснение, наверное

какие-то ответственности владеющей сущности могут делегироваться составной сущности

https://github.com/piscolomo/ruby-patterns/blob/master/README.md#composite похоже?

это скорее агрегат

и то, нет, не думаю что это можно отнести к агрегатам

жесткая свяь между сущностями, где одна сущность является частью другой. Хотя это так себе объяснение, наверное

Вот есть у тебя Rack::Request, нужно посчитать количество вызовов его метода params в определённом месте, как ты предлагаешь решить?

wrapper-proxy какойнить его завернуть

wrapper-proxy какойнить его завернуть

Чем это лучше наследования?

Чем это лучше наследования?

хз. не могу представить контекст. интересно услышать от Никиты)

Чем это лучше наследования?

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

Могу лишь предположить что разница в инкапсуляции. Наследование её по сути нарушает.

когда говорят "предпочитайте композицию наследованию" имеют в виду "при построении своих систем", а не "при улучшении чужих"

Всем привет ищу удаленщика на ruby back end , подробно в личку

Могу лишь предположить что разница в инкапсуляции. Наследование её по сути нарушает.

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

а ну значит я таки подсознательно прав :)

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

"программирование ни о чём" того же уровня аргумент

когда говорят "предпочитайте композицию наследованию" имеют в виду "при построении своих систем", а не "при улучшении чужих"

Наследование — построение своей системы на основании другой

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

И проксировать все необходимые методы? Чем лучше наследования? Я вижу только больше кода

если у объекта правильный интерфейс, то проксировать там мало что нужно. Ну а если неправильный, то есть method_missing

я тут разбрасываюсь немного «правильный»/«неправильный», но все же

если у объекта правильный интерфейс, то проксировать там мало что нужно. Ну а если неправильный, то есть method_missing

Допустим. Так чем лучше?

Третий раз задаю этот вопрос ?

я как бы попытался намекнуть на инкапсуляцию, интерфейсы, SOLID и прочее, у меня нет времени детально объяснять чем это лучше, чем расширение через наследование

я как бы попытался намекнуть на инкапсуляцию, интерфейсы, SOLID и прочее, у меня нет времени детально объяснять чем это лучше, чем расширение через наследование

то есть очевидной выгоды всё-таки нет?

я как бы попытался намекнуть на инкапсуляцию, интерфейсы, SOLID и прочее, у меня нет времени детально объяснять чем это лучше, чем расширение через наследование

Принцип открытости/закрытости основан на наследовании — об этом везде написано

я как бы попытался намекнуть на инкапсуляцию, интерфейсы, SOLID и прочее, у меня нет времени детально объяснять чем это лучше, чем расширение через наследование

Не смог найти инфы, где говорится "не используйте наследование, используйте проксирование через самобытные классы". Везде упоминается именно наследование. Если скинешь — буду рад и благодарен, любопытно

то есть очевидной выгоды всё-таки нет?

очевидность субъективна, скажем так, композиция должна быть вариантом по умолчанию, потому что в большинстве случае ее 1) достаточно, 2) нужно меньше думать о том что там внутри у объекта, 3) это помогает давать объектам разумные интерфейсы

Не смог найти инфы, где говорится "не используйте наследование, используйте проксирование через самобытные классы". Везде упоминается именно наследование. Если скинешь — буду рад и благодарен, любопытно

находится по запросу composition over inheritance https://en.wikipedia.org/wiki/Composition_over_inheritance

может они и есть но они не нужны.

мьютекс ведь используется в прикладном коде, чтобы защитить какую-то часть Ruby кода от прерывания "на середине" вернее, прирывание будет, то другой поток туда зайти не сможет а GIL относится только к C-коду это же разные уровни

GIL, кстати, не гарантирует что не получится 1+1 = 1, хотя в почти 100% будет 2

находится по запросу composition over inheritance https://en.wikipedia.org/wiki/Composition_over_inheritance

Спасибо. 1. В "плохом" примере приводится как аргумент "diamond problem", что вытекает из множественного наследования, чего нет в руби 2. В "хорошем примере" используется наследование 3. Тут как будто речь больше о композиции из интерфейсов, миксинов, а не "проксей" 4. Всё это в контексте плюсов Хммм ? Слабенько

надо ещё 4 пункта, да?)

GIL, кстати, не гарантирует что не получится 1+1 = 1, хотя в почти 100% будет 2

А разве это не цель GIL? Гарантировать 1+1=2

надо ещё 4 пункта, да?)

Используйте функцию ответов, пожалуйста. Вы кому писали, мне?

Используйте функцию ответов, пожалуйста. Вы кому писали, мне?

ага, просто думал если прям под репликой, то не надо

наследование идеологически - это родственная связь. типа похожие объекты. а в случае с Rack::Request и кастомной поделкой, никакой родственности нет

4 пункта я привёл того, что эта аргументация не согласуется с желанием людей проксю вкорячить

4 пункта я привёл того, что эта аргументация не согласуется с желанием людей проксю вкорячить

сорян, я не так прочёл

наследование идеологически - это родственная связь. типа похожие объекты. а в случае с Rack::Request и кастомной поделкой, никакой родственности нет

Да блин, есть она! Мне нужен всё тот же реквест, который просто умеет считать количество обращений к одному из своих методов, и всё

Да блин, есть она! Мне нужен всё тот же реквест, который просто умеет считать количество обращений к одному из своих методов, и всё

ну так можно что угодно прикрутить. надо оперировать "высокоуровневыми" требованиями

Я этот реквест и тестирую по сути в том месте. Его сына, так сказать

ну так можно что угодно прикрутить. надо оперировать "высокоуровневыми" требованиями

Не аргумент

Не аргумент

а если надо допустим сериализовать реквест в csv- это тоже задача Request? тоже добавим миксин?

ещё раз, composition over inheritance - это про построение новых систем, не про адаптацию существующих

ERROR: S client not available

Композиция или наследование: как выбрать? / Хабрахабр https://m.habrahabr.ru/post/325478/

Вот, перевод охуенной статьи. Ещё раз убедился, что я прав и не больной

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

#работа Middle / senior RoR разработчик / Team lead Мы в компании seendex.ru (Москва) ищем на full-time middle / senior RoR разработчика. Занимаемся разработкой B2B saas для автоматизации оценки уровня развития компаний и мониторинга эффективности коллектива. Основные задачи: - разработка архитектуры системы - бекенд для расчётов - помощь джуниорам Используем рельсы 5.1.1, стандартный рельсовый набор (постгрес, rspec, sidekiq, всё такое), есть проекты на crystal. Любим классы и ООП. з/п - до 180к рублей, офис в БЦ на м. Юго-Западная. Из минусов: - немного бюррократии - рабочий день должен начинаться не позже 11:00 - нет печенек Из плюсов: - предоставляем рабочий макбук или альтернативу - безлимитный кофе - открыты к использованию новых технологий - много пальм и света ?

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

Для теста одного метода в одном классе сомнительное преимущество)

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

Кто-нибудь вкурсе почему Rails.application.load_tasks ломает все тесты контроллеров?

Хотел протестировать рейк таску, но чтобы выполнить ее, нужно загрузить их

как именно ломает?

ActionView::Template::Error: No route matches

тестирую таски по этой статье, ошибок не возникает https://robots.thoughtbot.com/test-rake-tasks-like-a-boss

Да, тут очень хорошее решение, т.к. таски дублируются, а не используются текущие, спасибо!

А разве это не цель GIL? Гарантировать 1+1=2

В книге "Путь Руби" говорят что нет. Доверяю этому источнику.

В книге "Путь Руби" говорят что нет. Доверяю этому источнику.

на википедии говорят, что да. доверяю этому источнику, опровержений на практике не видел)

он жертвует параллельными вычислениями из-за этого преимущества

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

И что лучше использовать для этого специальные инструменты, а не полагаться на GIL

Может быть это не так, но станно тогда это всё

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

интересны кейсы

Об этом увы там умолчали

Но я на всякий случай принял во внимание

я не отрицаю, но любопытно. так-то можно сказать, что puts всегда выводит строку, но есть исключения, а какие — мы вам не скажем)

:001 > i = 0 => 0 :002 > 5.times.map { Thread.new { 1000.times { i += 1; sleep(rand(100) / 10000.0) } } }.join :003 > i => 1686 :004 > ruby -v ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16]

join не сработал? Если подождать, то i будет равно 5000

а, точняк)

join не сработал? Если подождать, то i будет равно 5000

join не у той скобки, да

классный кейс) вот я о таких именно и предполагал: когда программист косячит

нужно было map(&:join)

join у той скобки, только надо .each(&:join)

есть же ruby under microscope, я до нее не добирался, но мне кажется там должно быть это описано