В Ruby нет разницы между библиотекой и расширением — это всё gem-ы.
По-умолчанию они ставятся в систему, с появлением bundler-а куда хочется — чаще всего в папку с проектом, т.е. не нужны права суперпользователя.
Но и в первом случае нет никаких системных ruby.ini файлов, которые задают как должны работать проекты, использующие его.
Главный недостаток PHP, по-моему, это даже не знаки доллара перед переменными и не согласованные сигнатуры стандартных функций, а тот факт, что многие вещи задаются настройками самого интерпретатора, подключаемыми к нему расширениями и т.д.
Ввиду чего использование того же composer несколько ограничено. Раньше, видимо, поэтому и сделали общесистемный PEAR по аналогии с расширениями.
В каком ещё интерпретируемом языке такое есть?
Из своего опыта скажу следующее:
1. Тесты контроллеров, как правило, не окупают себя — они пишутся дольше всего и наиболее чувствительны к изменением тестируемого кода. Лично по мне — в рельсах лучше максимально отказаться от тестов контроллеров (оставить только там где это необходимо), а писать интеграционные тесты — т.е. именно слать запросы get, put, post, delete и т.д. на нужные адреса, либо кликать по ссылкам.
Вы же не тестируете каждую вьюху? Хотя такая возможность тоже есть.
2. Лучше всё же shared examples. Решается просто — весь общий код пишется, собственно, в него, а нужные переменные передаются через let:
it_behaves_like "protected controller" do
let(:method) { 'hello' }
end
По мне, основное и главное свойство тестов (помимо того что они тестируют нужный функционал) — это их читаемость.
Непонятные тесты, которые дают 100% покрытия — не тот результат, к которому бы я стремился. Понятные читаемые тесты, тестирующие большинство ситуаций + самые критичные места — это моя цель.
В Мадженто DI для классов сущностей нигде не передается DI контейнер (ObjectManager в терминологии Мадженто), только сущности, которые необходимы конкретному классу.
DI контейнер и не должен никуда передаваться. Передаётся сервис локатор.
Или вот это?
Более того, когда в Мадженто 1 данная модель содержала в себе все те же зависимости, но использовала внутри себя Service Locator для их инстанциации этого никто не замечал и все с этим жили. DI показал много проблем в зависимостях у классов и модулях, между которыми не должно быть этих зависимостей.
Почему пишется про сервис локатор, и потом как следствие упоминаются проблемы в DI?
И каким образом DI создаёт эти проблемы? Тем более что в приведённом коде самый настоящий DI.
Мадженто 2 предоставляет Service Layer набор публичных API интерфейсов у каждого из модулей, и именно эти интерфейсы предполагаются будут использованы и расширены (плагинизированы) 3rd party программистами.
Насколько мне известно, большая часть авиакатастроф, а тем более со смертельным исходом, происходят во время взлёта и посадки.
Непонятно как здесь поможет такая система.
Несмотря на всё это, method_missing это не единственный способ. В Вашем примере с UTF он лучше, но не единственный.
И всё это не отменяет недостатка в виде лапши в stack trace.
Ваше мнение, на мой взгляд, слишком категорично, а его изложение изобилует переходами на личности.
Плохо тем что будет длинная цепочка через super. Чисто эстетически это плохо, т.к. делает stack trace необоснованно длинным. Не могу сказать, что это сильно затрудняет отладку, но точно добавляет мусор.
respond_to? или respond_to_missing? — не важно что вы переопределите — вам придётся делать это, т.е. переопределять сразу 2 метода.
Систему плагинов в ряде случаев можно сделать точно также, но с использованием define_method — и не нужно ничего переопределять.
В некоторых случаях, конечно, без method_missing не обойтись, но весь посыл в том, чтобы использовать его только когда это необходимо.
Я бы добавил, что единственное более менее оправданное использование method_missing это когда ваш метод может в любой момент времени существовать или нет — как на примере хэша.
В случае же если это делается из удобства, например хотите прописать в классе одну строчку вроде
Пример с Васей плохой.
Наказание, всё же, это последнее средство. И наказывать нового сотрудника за то что он сделал больше чем требовалось в первый раз некорректно и непродуктивно.
Более того, считаю, что наказания допустимы только в случае осознанных провинностей и непосредственной вины.
Если Лена регулярно и осознанно посылает Васю подальше — она заслуживает кары.
А если свет, отражённый от Сатурна убил RAID, администратор тут ни при чём. Если он недостаточно компетентен, его либо нужно уволить (хотя как он до этого сюда попал), либо повысить его навыки.
По-умолчанию они ставятся в систему, с появлением bundler-а куда хочется — чаще всего в папку с проектом, т.е. не нужны права суперпользователя.
Но и в первом случае нет никаких системных ruby.ini файлов, которые задают как должны работать проекты, использующие его.
Ввиду чего использование того же composer несколько ограничено. Раньше, видимо, поэтому и сделали общесистемный PEAR по аналогии с расширениями.
В каком ещё интерпретируемом языке такое есть?
1. Тесты контроллеров, как правило, не окупают себя — они пишутся дольше всего и наиболее чувствительны к изменением тестируемого кода. Лично по мне — в рельсах лучше максимально отказаться от тестов контроллеров (оставить только там где это необходимо), а писать интеграционные тесты — т.е. именно слать запросы get, put, post, delete и т.д. на нужные адреса, либо кликать по ссылкам.
Вы же не тестируете каждую вьюху? Хотя такая возможность тоже есть.
2. Лучше всё же shared examples. Решается просто — весь общий код пишется, собственно, в него, а нужные переменные передаются через let:
По мне, основное и главное свойство тестов (помимо того что они тестируют нужный функционал) — это их читаемость.
Непонятные тесты, которые дают 100% покрытия — не тот результат, к которому бы я стремился. Понятные читаемые тесты, тестирующие большинство ситуаций + самые критичные места — это моя цель.
DI контейнер и не должен никуда передаваться. Передаётся сервис локатор.
Или вот это?
Почему пишется про сервис локатор, и потом как следствие упоминаются проблемы в DI?
И каким образом DI создаёт эти проблемы? Тем более что в приведённом коде самый настоящий DI.
связано с таким жирным конструктором?
И почему вы под DI понимаете Service Locator?
Непонятно как здесь поможет такая система.
И всё это не отменяет недостатка в виде лапши в stack trace.
Ваше мнение, на мой взгляд, слишком категорично, а его изложение изобилует переходами на личности.
respond_to? или respond_to_missing? — не важно что вы переопределите — вам придётся делать это, т.е. переопределять сразу 2 метода.
Систему плагинов в ряде случаев можно сделать точно также, но с использованием define_method — и не нужно ничего переопределять.
В некоторых случаях, конечно, без method_missing не обойтись, но весь посыл в том, чтобы использовать его только когда это необходимо.
А ещё вам придётся определять respond_to?
В случае же если это делается из удобства, например хотите прописать в классе одну строчку вроде
и получить методы вроде
, то в таком случае мне ближе подход через define_method. В таком случае будет создан полноценный метод.
Наказание, всё же, это последнее средство. И наказывать нового сотрудника за то что он сделал больше чем требовалось в первый раз некорректно и непродуктивно.
Более того, считаю, что наказания допустимы только в случае осознанных провинностей и непосредственной вины.
Если Лена регулярно и осознанно посылает Васю подальше — она заслуживает кары.
А если свет, отражённый от Сатурна убил RAID, администратор тут ни при чём. Если он недостаточно компетентен, его либо нужно уволить (хотя как он до этого сюда попал), либо повысить его навыки.