Основная проблема в том, что контр\ковариантность в пхп пока не смогли, потому что это создает какие то проблемы в разработке енамов.
то если у Razor есть наследники (положим, это библиотека), то изменить сигнатуру указанным образом невозможно, это тут же нарушает LSP для наследников.
Если же сделать нового «правильного» наследника, с нужной сигнатурой, то текущая версия PHP кидается ворнингами (т.к. пока мы живем с инвариантами)
Так что это полумера, но это единственное что позволяет перейти от одного интерфейса к другому с сохранением обратной совместимости и без особых костылей. Хотя если вы знаете короткий путь, то готов посмотреть
А я не говорил, что это определение. Это одно из следствий со стороны обсуджаемого вопроса.
Если вы хотите строго по определению, то пожалуйста. Представьте, что у вас есть тип T с методом T::f(A $a). И есть тип S extends T с методом, который отличается только отсутствием тайпхинта S::f($a).
Если сам код методов идентичен, то если свойство q(T x) верно, то и свойство q(S y) тоже будет верным
Таким образом исключение тайпхинта не нарушает LSP, а текущее поведение (фатал парсера) — нарушает. Что подтверждает мое утверждение
Как раз таки этот «вброс» ведет к частично более полному соблюдению LSP, в этом и суть.
Если кратко, то LSP состоит в том, что множество допустимых входных параметров вы можете только расширять, а множество возможных выходных параметров вы можете только сужать.
Сброс тайп-хинта сигнатуры позволит вам реализовать прослойки для управления обратной совместимостью, при этом сигнатуры вы все еще можете определять через phpdoc
Вот чего я не могу понять — а можно ли хранить граф НЕ в коде. Если можно, то тогда можно будет делать крутые штуки для бизнес-процессов, а-ля workflows в JIRA
Не воспринимаю Yii как серьезный фреймворк с тех пор как осознал, что у них все встроенные вещи построены на обязательных паблик полях. В лучшем случае на protected, в случае с AR. Вкупе со статикой люди начинают делать из этого АД. во второй версии все то же самое.
Аналогично. Первая мысль, которая придет мне в голову, если я начну клепать сайты на симфони раз в неделю — это сделать свой отдельный пакет и разворачивать его через create-project
Скорей всего ядро будет ориентироваться только на прямые зависимости. Автоконфигурация будет производиться тоже за счет наличия явно подключенного пакета.
Например есть компонент symfony/form. При его наличии в секции require будет происходить установка ключа framework.forms в положение ~. Аналогично, если установлен метапакет, замещающий symfony/form (например, symfony/symfony)
Это уже реализовано в 3.3-dev. Аналогично можно поступать с другими пакетами. Бандлам, я полагаю, будет предложено иметь «дефолтную конфигурацию» и\или иметь стандартные точки расширения, например какой нибудь symfony/security-bundle с помощью symfony/doctrine-bridge может найти единственную сущность, имплементирующую UserInterface и автоматически подключить в качестве провайдера пользовательских аккаунтов. Zero-configuration.
Фантазировать можно много, идея в целом годная. Остается только ждать )
Про крон команду с вами уже обсуждают в другом треде, не буду повторяться. Не считаю удобным дергать все ядро раз в минуту вне зависимости от того, должно что-то отрабатывать или нет. Есть консольные команды, которые можно запускать хоть руками, хоть кроном
Сорян, замыленый глаз прочитал не так :) Есть подозрение, что готовых интеграций тоже хватает https://packagist.org/packages/oneup/flysystem-bundle. Про решение «изкоробки» уже обсуждали — зачем оно всем подряд? Например при работе с сервисной архитектурой все проекты подряд скорей всего не будут грузить файлы, а будет один сервис для этого
form login хватает для классики. для внешней авторизации (хавоть чужую куку или апи какое хитрое авторизовать) этого уже мало, Guard принес много радости детишкам по поводу этого вопроса
технически standard edition — это готовое boilerplate приложение на основе symfony fullstack (symfony\symfony) и доп. либ. официальное, православное. а сам фрейм отдельно, как вы указали
Нет, сфитмейлер умеет спулить емейлы. Либо откладывать до terminate ядра (т.е. шлет после отправки ответа пользователю, завершая коннект), либо можно спул обрабатывать внешним потоком (кроном, например). По умолчанию спул в памяти, отправка по терминейт
Деплой должен настраивать такие штуки. Потому что это вещи, зависящие от окружения. В ином окружении (дев, тест) у нас такие вещи отключены или поставлены на более щадящие таймеры. В препрод, прод — работают. В проекте есть отдельный конфиг для whenever (так сложилось), который при деплое развертывается в готовый крон файл, этим же CI\CD отключается при откате релиза и прочее. А как вы отключаете ваши кроны при откате релиза?
Filesystem — это часть пакета symfony/symfony (есть по вашей ссылки). symfony/symfony заменает filesystem. Можно установить отдельным пакетом
FoS UB, если вы про него — это готовые пользователи, которые надо отметить, опять же не всем подходят. У нас на всех проектах авторизация внешняя, юзеры вообще в битриксе живут (так сложилось). Авторизация работает, в том числе встроенная симфонёвая. Есть проект с FoS UB (точней там Sonata Admin, которая тянет FoS UB
Ок, не сталкивался, видимо
Да, потому что технически это такая же внешняя библиотека, как доктрина. Поэтому она идет изкоробки в standard (как доктрина), но это не часть проекта symfony. Сути ссылки я не понял. Вижу что можно все подключить модулями.
Не только в доктрине, есть knp pagination bundle, довольно удобная штука, умеет пагинировать не только доктрину, а много разных источников
Большинство этих вещей устанавливаются в два клика пару команд — composer require и подключение в ядро. Ну и список такой себе сомнительный.
1 — спорно, это все таки решение конкретных задач по управлению потоком
2,3 — это не задача проекта, а задача CI\CD, системы сборки (capistrano, deployer, выбирайте по вкусу). В «большинстве проектов сложней бложика», если говорить вашими терминами, эти вещи уже управляются снаружи.
4 — Filesystem есть изкоробки, я не зря привел вам пример пакета, в котором есть ВСЕ пакеты симфони
5 — Есть нормальное с версии 2.8, до 2.8 тоже можно было использвать, но чуть сложней (больше кода писать). Сейчас (с 2.8) достаточно заимплементить один интерфейс.
6 — не очень понял, что это именно
7 — есть, свифтмейлер из коробки. Телеграм из коробки — а почему не ватсап? скайп? Почему фреймворк за вас выбирает канал? Опять же — куча готовых модулей. Выбираете свой и подключаете.
8 — готовый бандл
9 — готовый бандл, но иногда действительно рекомендуют alice
Если доставлять приходится во всех, то вы давно могли сделать свой метапакет, типа того же symfony/framework-standard-edition и переиспользовать его. Есть, кстати и rest-edition. А так вы видимо просто делаете что-то однотипное.
У нас сейчас используется микросервисная архитектура и проекты на симфони и все разные. На половине из них все то, что вы написали не нужно.
Скорее наоборот. В Laravel из коробки на несколько порядков больше возможностей. В симфони же почти всё ставится руками, всегда, начиная с flysystem, заканчивая всякими monolog, swiftmailer и проч.
А вы точно пробовали пакет symfony/symfony и symfony/framework-standard-edition? Это как раз для тех, кто хочет готовый комбайн под новый проект, если что. Потом можно ненужные вещи (твиг, например, в АПИ не пригодился) — выпилить
С чего бы эвенты надо закидать камнями? Эвенты — это документированная точка расширения вашего приложения, вы как бы говорите разработчикам — «Э-гей, вот здесь вы можете изменить мир данные или отреагировать на них, вот вам событие, которое их инкапсулирует». Событие вполне себе может быть VO, если планируется только реакция на событие, или может быть мутирующим, если вы хотите чтобы расширения как-то дополнили или изменили ваши данные. Т.е. вы сами полностью управляет процессом реакции на события за счет паттернов.
Не знаю за ларавель, но в симфони евенты, как и все остальное, полностью DIC-based, это значит что можно найти все зарегистрированные листнеры (либо посмотреть в рантайме, если вы подписываетесь в рантайме).
Синглтоны и статические фасады же позволяют вам обращаться, в том числе к мутирующим сервисам из любого места, что обычно при недостатке контроля или компетенции приводит к лапше в коде.
Я в целом согласен с Fesor, однако уточню, что в целом можно писать какой угодно код, если он никогда не будет никому показан. В противном случае лучше пользоваться вот теми самыми принципами из питона выше.
Там не в парсере дело, а в том, что при вызове консоли приложение регистрирует ВСЕ команды из ВСЕХ бандлов принудительно (и не лениво в данный момент). Если команд действительно много — это может стать проблемой. Но я до такого пока не доходил. В принципе всегда можно оформить PR с фиксом этой фичи, я например не вижу никакой принципиальной проблемы сделать их ленивыми сервисами или инициализировать лениво через замыкания
Это такой себе аргумент. IDE уже давно все автокомплитит, причем с учетом типов.
Лично я больше рассматриваю эти фасады как антипаттерн, который позволяет разработчикам обращаться к сервисам из мест, абсолютно для этого не предназначенных. Поощряет написание лапши, имхо.
то если у Razor есть наследники (положим, это библиотека), то изменить сигнатуру указанным образом невозможно, это тут же нарушает LSP для наследников.
Если же сделать нового «правильного» наследника, с нужной сигнатурой, то текущая версия PHP кидается ворнингами (т.к. пока мы живем с инвариантами)
https://externals.io/thread/514
https://wiki.php.net/rfc/return_types#variance_and_signature_validation
Так что это полумера, но это единственное что позволяет перейти от одного интерфейса к другому с сохранением обратной совместимости и без особых костылей. Хотя если вы знаете короткий путь, то готов посмотреть
Если вы хотите строго по определению, то пожалуйста. Представьте, что у вас есть тип T с методом T::f(A $a). И есть тип S extends T с методом, который отличается только отсутствием тайпхинта S::f($a).
Если сам код методов идентичен, то если свойство q(T x) верно, то и свойство q(S y) тоже будет верным
Таким образом исключение тайпхинта не нарушает LSP, а текущее поведение (фатал парсера) — нарушает. Что подтверждает мое утверждение
Если кратко, то LSP состоит в том, что множество допустимых входных параметров вы можете только расширять, а множество возможных выходных параметров вы можете только сужать.
Сброс тайп-хинта сигнатуры позволит вам реализовать прослойки для управления обратной совместимостью, при этом сигнатуры вы все еще можете определять через phpdoc
тык
тык
+ Guads (3.3)
Вот чего я не могу понять — а можно ли хранить граф НЕ в коде. Если можно, то тогда можно будет делать крутые штуки для бизнес-процессов, а-ля workflows в JIRA
Скорей всего ядро будет ориентироваться только на прямые зависимости. Автоконфигурация будет производиться тоже за счет наличия явно подключенного пакета.
Например есть компонент symfony/form. При его наличии в секции require будет происходить установка ключа framework.forms в положение ~. Аналогично, если установлен метапакет, замещающий symfony/form (например, symfony/symfony)
Это уже реализовано в 3.3-dev. Аналогично можно поступать с другими пакетами. Бандлам, я полагаю, будет предложено иметь «дефолтную конфигурацию» и\или иметь стандартные точки расширения, например какой нибудь symfony/security-bundle с помощью symfony/doctrine-bridge может найти единственную сущность, имплементирующую UserInterface и автоматически подключить в качестве провайдера пользовательских аккаунтов. Zero-configuration.
Фантазировать можно много, идея в целом годная. Остается только ждать )
в два кликапару команд — composer require и подключение в ядро. Ну и список такой себе сомнительный.1 — спорно, это все таки решение конкретных задач по управлению потоком
2,3 — это не задача проекта, а задача CI\CD, системы сборки (capistrano, deployer, выбирайте по вкусу). В «большинстве проектов сложней бложика», если говорить вашими терминами, эти вещи уже управляются снаружи.
4 — Filesystem есть изкоробки, я не зря привел вам пример пакета, в котором есть ВСЕ пакеты симфони
5 — Есть нормальное с версии 2.8, до 2.8 тоже можно было использвать, но чуть сложней (больше кода писать). Сейчас (с 2.8) достаточно заимплементить один интерфейс.
6 — не очень понял, что это именно
7 — есть, свифтмейлер из коробки. Телеграм из коробки — а почему не ватсап? скайп? Почему фреймворк за вас выбирает канал? Опять же — куча готовых модулей. Выбираете свой и подключаете.
8 — готовый бандл
9 — готовый бандл, но иногда действительно рекомендуют alice
Если доставлять приходится во всех, то вы давно могли сделать свой метапакет, типа того же symfony/framework-standard-edition и переиспользовать его. Есть, кстати и rest-edition. А так вы видимо просто делаете что-то однотипное.
У нас сейчас используется
микросервисная архитектура и проекты на симфони и все разные. На половине из них все то, что вы написали не нужно.А вы точно пробовали пакет symfony/symfony и symfony/framework-standard-edition? Это как раз для тех, кто хочет готовый комбайн под новый проект, если что. Потом можно ненужные вещи (твиг, например, в АПИ не пригодился) — выпилить
https://packagist.org/packages/symfony/symfony
https://packagist.org/packages/symfony/framework-standard-edition
мирданные или отреагировать на них, вот вам событие, которое их инкапсулирует». Событие вполне себе может быть VO, если планируется только реакция на событие, или может быть мутирующим, если вы хотите чтобы расширения как-то дополнили или изменили ваши данные. Т.е. вы сами полностью управляет процессом реакции на события за счет паттернов.Не знаю за ларавель, но в симфони евенты, как и все остальное, полностью DIC-based, это значит что можно найти все зарегистрированные листнеры (либо посмотреть в рантайме, если вы подписываетесь в рантайме).
Синглтоны и статические фасады же позволяют вам обращаться, в том числе к мутирующим сервисам из любого места, что обычно при недостатке контроля или компетенции приводит к лапше в коде.
Я в целом согласен с Fesor, однако уточню, что в целом можно писать какой угодно код, если он никогда не будет никому показан. В противном случае лучше пользоваться вот теми самыми принципами из питона выше.
Это такой себе аргумент. IDE уже давно все автокомплитит, причем с учетом типов.
Лично я больше рассматриваю эти фасады как антипаттерн, который позволяет разработчикам обращаться к сервисам из мест, абсолютно для этого не предназначенных. Поощряет написание лапши, имхо.