PHP-Дайджест № 100 – интересные новости, материалы и инструменты (1 – 15 января 2017)

А что плохого с принципом случится, если foo все еще будет работать с (в том числе и) массивом?

А как же принцил Лисков?

Вы либо плохо читали RFC, либо подзабыли LSP. LSP разрешает расширение входных параметров и данный RFC как раз таки направлен на то, чтобы соответствовать LSP.

Т.е. если у вас есть класс-наследник с методом, расширяющим сигнатуру базового, то это не противоречит LSP, но в то же время позволяет оперировать терминами будущей совместимости (например вы можете расширить класс, чтобы они принимал не только array, но и \Traversable, и задеприкейтить старый для следующего мажороно релиза). В нынешней реализации это вызовет ошибку

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

class Parent
{
    /** @param string|int $bar */
    public function foo($bar)
    {
        ...
    }
}

Согласно «контракту» метод foo должен принимать на вход аргумент строкового или целочисленного типа.

И есть использование:

/**
 * @param Parent     $qux
 * @param string|int $arg
 */
function baz(Parent $qux, $arg)
{
    $qux->foo($arg);
}

Тут мы говорим о том, что на вход должен поступить объект, являющийся инстансом класса Parent, и в метод foo этого объект мы передаём аргумент. Так как контракт метода foo говорит о том, что на вход должен поступить либо строковой либо целочисленный аргумент, то и переменная $arg тоже должна быть либо строкового, либо целочисленного типа.
Тут всё логично.

Теперь представим, что есть класс

class Child extends Parent
{
    public function foo(int $bar)
    {
        ...
    }
}

, перегружающий метод foo и сужающий его ОДЗ.
В этой ситуации мы инстанс класса Child уже не можем передать в функцию baz поскольку метод в дочернем классе сужает ОДЗ, а значит мы не можем передать в метод foo аргумент строкового типа. Таким образом мы имеем нарушение LSP.

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

Таким образом, LSP говорит о том, что субтипы не должны сужать супертип. В том числе, переопределение метода в субтипе может расширять ОДЗ метода, но не должно сужать его.

Извините, если ответ получился запутанным или сумбурным.

Подскажите, как это преобразовывается?

Спасибо!

Справедливости говоря, на крупных проектах Ларка действительно даст фору Симфони (могу лишь сравнивать с ней, опыта с Zend маловато, чтобы утверждать что-то наверняка). Вся фишка в схеме работы и архитектуре:

Внутри Симфони
1) Сбилженный контейнер со всеми сервисами (frozen)
2) Каждый запрос обрабатывается тучей эвентов из разных мест
3) Внутрь контроллеров всовываются в конструктор сервисы через DI
4) Каждый запрос обрабатывают тучи гвардов

Внутри Ларки
1) Контейнер создаётся лениво, в зависимости от поведения приложения
2) Вместо кернел эвентов миддлвари, которые вешаются на определённый запрос, а не на все
3) Сервисы в контроллеры попадают через двойную диспатчеризацию (т.е. как объект Request в контроллеры в симфони)
4) Гвардов в ларке вообще нет, их ответсвенность берут на себя миддлвари, которые см. п.2 — на каждый запрос (или группу запросов) свои.

Подытоживая — из подобной схемы работы ларка более тяжеловесна в сыром виде, симфони же после билда контейнера (в продакшн режиме, например) — летает, но при увеличении количества бандлов в проекте на симфони — жручесть его увеличивается по экспоненте, а ребилд всего в дев режиме может достигать десятков секунд. Доходило до такого, что обычная страничка в сонате (правда с xdebug) отжирала до 100+ мегабайт. В случае же ларки потребление оперативы почти не растёт, т.к. добавление провайдера лишь добавляет дефинишн (зачастую интерфейс, а не алиас сервис-локации, как в симфони) для DI, а он уже загружается когда потребуется в том месте, где он используется и только в нём. Т.е. чистый старт ларки содержит почти что пустой контейнер, в тоже время в симфони он полностью заполненный из всех бандлов.

P.S. Я люблю оба фреймворка, они оба замечательные по-своему =)

Есть еще новость: Yii2 Application Development Cookbook, Дмитрий Елисеев, вчера опубликовал в своем блоге

в декабре еще вышла, новость есть в прошлом, 99-м, выпуске