В
Да, перестанет, но в твоем варианте от этого он работать не станет.
Оба наши варианты не идеальны, это точно :)
Size: a a a
2020 June 29
NO
Плюс моего подхода в том, что в работающем приложении реализацию контейнеров не меняют. А вот изначально попытаться совместить разные реализации могут. И тут наличие второго интерфейса спасает.
это почему?)
В
это почему?)
Не 100%, но таки крайне редко такое происходит)
NO
ничего не меняют только в неработающем приложении... в работающем может меняться всë что угодно)
В
Какой вариант используем для фикса композитного контейнера? https://github.com/yiisoft/di/pull/134
Анонимный опрос
Проголосовало: 2DS
Плюс моего подхода в том, что в работающем приложении реализацию контейнеров не меняют. А вот изначально попытаться совместить разные реализации могут. И тут наличие второго интерфейса спасает.
Усугубляет. Пойми, если твой набор публичных методов не соответствует интерфейсу, то это потенциальная возможность нарушить интерфейс, что приведет к невозможности использовать этот пср вообще в принципе. В моем случае это приведет только к неоднозначности, что тоже не очень хорошо, но прокатит во многих случаях.
В
Усугубляет. Пойми, если твой набор публичных методов не соответствует интерфейсу, то это потенциальная возможность нарушить интерфейс, что приведет к невозможности использовать этот пср вообще в принципе. В моем случае это приведет только к неоднозначности, что тоже не очень хорошо, но прокатит во многих случаях.
Нене, как раз наоборот. Использование методов, описанных в интерфейсе, с набором параметров, этому интерфейсу не соответствующему, 100% ломает совместимость рано или поздно, и тут без вариантов. Второй же интерфейс можно деть куда угодно, хоть в другом классе реализовать.
В
Какой вариант используем для фикса композитного контейнера? https://github.com/yiisoft/di/pull/134
Анонимный опрос
Проголосовало: 2Мне кажется, мы слишком много времени потратили на довольно мелкое изменение. Айда решать что-то)
DS
Нене, как раз наоборот. Использование методов, описанных в интерфейсе, с набором параметров, этому интерфейсу не соответствующему, 100% ломает совместимость рано или поздно, и тут без вариантов. Второй же интерфейс можно деть куда угодно, хоть в другом классе реализовать.
Второй интерфейс можно только через наследование, делаешь новый интерфейс и айда, тогда все будет ок, только об остальных контейнерах следующих пср можешь забыть)
В
Второй интерфейс можно только через наследование, делаешь новый интерфейс и айда, тогда все будет ок, только об остальных контейнерах следующих пср можешь забыть)
Причем тут вообще наследование?
В
зачем?
NO
прочитал, но не понял
В
Остальные контейнеры, как и в твоем случае, просто будут некорректно работать в некоторых кейсах с композитным контейнером
NO
объясните, почему не проходит тест
NO
Мне кажется, мы слишком много времени потратили на довольно мелкое изменение. Айда решать что-то)
наоборот, поспешность только вредит. особенно если это ключевой компонент фреймворка)
DS
Причем тут вообще наследование?
Потому что, если у тебя интерфейса, то ты можешь получить инстанс по одному интерфейсу, а юзать методы второго.
В
Потому что, если у тебя интерфейса, то ты можешь получить инстанс по одному интерфейсу, а юзать методы второго.
мне кажется, у тебя тут опечатка
DS
Остальные контейнеры, как и в твоем случае, просто будут некорректно работать в некоторых кейсах с композитным контейнером
Шанс того, что композитный контейнер будет работать некорректно одинаков в обоих случаях.
DS
мне кажется, у тебя тут опечатка
В чем?
В
В чем?
Знать бы...