Неа. Достаточно while с continue и со сменой стейта. А peg или parser-combinator вообще даже без continue можно. Последний вообще через рекурсию, тупо с новыми аргументами (которые опять же можно развернуть в обычный while с массивом/вектором из стека).
Короче, goto не нужен. Только если хочется сделать одну километровую говнокодистую портянку сразу со всеми видами состояний, да и то спорно.
Ну т.е. у вас всё своё, нет ни единой библиотеки на PHP из композера, т.к. сам композер не работает, но при этом "это чуть-чуть другой рантайм", я правильно понял?)))
P.S. И с каких пор конструкции, полностью поддерживающиеся IDE, с работой автокомплита, с покрытием стат.анализатором, без каких либо инструментов метапрограммирования (get/set/call) и прочим называется "магией"?
KPHP вполне собирает код на PHP 7.4. И хотя есть свои дополнения, но они не мешают исполнению в PHP режиме.
А у вас приложение на Symfony, Laravel, Laminas или может быть Slim с Doctrine? Или всё же "просто другой рантайм" оказался не таким уж и "простым" и всё пришлось написать с нуля, т.к. язык всё же другой с похожим синтаксисом, верно?
P.S. У меня позиция, что для быстрых приложений достаточно воткнуть Swoole/RoadRunner/etc, а менять его на какой-нибудь Rust/C/Go уже только в случае критически важных секций, коих на практике оказывается обычно ровно 0.
Атрибуты, которые семантически должны представлять из себя классы метадаты отвечают ещё за валидацию. Смешение логики и правил маппингов.
В примерах кода не вижу вообще возможностей вынести правила валидации отдельно от DTO, например в yaml, php, json, etc. Чтобы правила можно было указывать во внешних файлах и изолировать от DTO.
Не вижу зависимых правил и сложных выражений, типа When X then (Y or Z). И даже реализовать подобное невозможно, кажется, учитывая то что в правила валидации приходит значение только одного поля.
Способа внедрить в конструктор в валидаторы тоже не вижу, т.к. см. п.1. Ну типа есть, например, сервис, предоставляющий анализ текста на "мат", как его всунуть в валидатор, чтоб сказать: #[DoesNotContainSwearWords(criteria: 0.2)], который уже делегируется нужному валидатору, который содержит инфу и локализации, и нужные коннекты к сервису и прочее.
Контекста и прочей инфы тоже нет, т.к. см. п.1
А в виде пакета как это поставить и посмотреть? Ну вот я хочу использовать у себя этот пакет отдельно в проекте, например...
Могу ещё накидать чем это хуже)
Ну т.е. если сравнивать с типичным кодом Битрикса, то это огромный шаг вперёд и выглядит на первый взгляд даже годно. Тут можно только поздравить, что у разработчиков наконец удалось написать код, от которого не хочется сразу вырвать себе глаза. Но это касается исключительно неймспейса Bitrix\Main\Validation\Xxx...
А если же сравнивать с тем же Symfony, то, например у меня, сразу возникает такой же вопрос "зачем": Т.к. фактически это копипаста существующего решения, но с худшей реализацией и наличием критичных (в т.ч. архитектурных) косяков, которые не позволяют нормально использовать этот компонент. Ну помимо того, что использовать его просто невозможно ввиду отсутствия в пакагисте)))
Отсюда, с точки зрения здравого смысла и этот вопрос: Зачем делать то, что и так существует, только архитектурно неправильно и в целом хуже? И варианта кроме как "потому что могут" тут, боюсь что нет.
А можно для немного тупеньких. Вот вы говорите про какие-то экспортные ограничения...
Если JB ушли с рынка РФ и ликвидировали юр.лицо, то разве это не означает, что не существует того, кто мог бы проконтролировать и предъявить за использование инструментов JB? Т.к. де-юре их (этих товаров) на территории РФ не существует, а значит и фактическая лицензия недействительна, следовательно и использовать можно без каких-либо ограничений.
Я не юрист, если что, просто интересно как упомянутые, цитата "экспортные ограничения", которых нет на территории РФ действуют на частное лицо на этой территории и почему это незаконно, как вы описываете.
Надо сажать не студентов, а профи в симфе и профи в ларе и дать им задачу запилить какое-либо ПО максимально всрато и в максимально сжатые сроки.
Ну, например, какой-нибудь сервис логина и регистрации акков с поддержкой OTLP мониторинга на уровне БД. И HTTP АПИ наружу, запрос-ответ, в каком-нибудь msgpack формате.
Чтобы модели ёлки кастовать в энтити можно взять JMS или Symfony Serializer. С другой стороны и троллейбус из хлеба можно сделать...
Ну и всё же это не столько "чистая архитектура", сколько конкретная репрезентация в виде гексагоналки. Хотя не спорю что что-то адекватнее или какую-либо альтернативу сложно придумать.
Я понял, я просто пояснил что я подразумевал под "фигак-фигак".
Этот "фигак-фигак" можно рассматривать как требования к разработке сервиса свыше от манагеров. Мол, "надо чтобы было сделано уже вчера". Это о чём я говорю.
А то о чём ты говоришь, "фигак-фигак" -- это не требования к ПО, а возможности разработчика, когда он кроме такого пути ничего просто не умеет.
RR и Swoole принципиально разные инструменты для совершенно разных задач. Одно тупо альтернатива FPM почти 1 в 1 с такой же однопоточной и блокирующей работой, а другое набор инструментов для написания асинхронных и многопоточных приложений, где просто есть в наличии API для работы с HTTP. Но не будем об этом...
Да, RR -- RoadRunner, просто полноценно живущий CGI, причём не самый быстрый, прошу заметить. Его преимущество только в том, что можно взять FPM и заменить на RR без каких-либо доработок и наоборот.
Но на всякий случай повторюсь, не используя всяких глобальных переменных, всяких статических шляп, синглтонов и прочего, ну т.е. запиливая обыкновенный адекватный код уровня миддла - рантаймы можно как перчатки менять. Примерно такие же правила хорошего тона, как "не завязываться на Apache". Вроде не рокет сайнс.
Не знаю, для меня "берешь студента и вуаля" и "фигак-фигак и в прод" это одно и то же разными словами :)
Ну всё же нет. Студент симфу не осилит просто, по-моему. А "фигак-фигак" вполне может быть техническим требованием к продукту.
все эти тщательно выписанные ентити
Получаем "тщательно выписанные энтити" vs "тщательно выписанные миграции". В ларке даже тут писанины больше, т.к. написать энтитю из которой сами миграции сгенерятся проще и быстрее, нежели вначале ап миграции, потом откат миграции, а потом ещё модель.
и конфиги
В симфе так же можно фигануть App\: { resource: "path/to/app" } и забыть про конфиги сервисов, сделав вид, что оно работает так же как в ларке. Ну да, тут побольше писанины на одну строчку!
Я же и говорю, при должном желании и компетенциях -- на симфе, имхо, почти всё получается быстрее, даже говнокод)
Поэтому и считаю что "фигак-фигак" и "вчерашний студент" - разные вещи, т.к. чтобы на симфе максимально лаконично и быстро что-то наклепать -- как минимум требуется знать где именно можно сократить что.
Не соглашусь (ну точнее не полностью). Имхо, основное преимущество Laravel в человеческих ресурсах, когда берёшь вчерашнего студента, сажаешь его на Laravel и вуаля, на выходе даже что-то работает. И там не то что фреймворк не обязательно знать, но и на PHP зачастую пофигу.
Ну потому что "фигак-фигак и в прод" можно и на симфе делать, и местами даже быстрее. Однако всё же квалификация под симфу требуется повыше.
Со статической типизацией же всё просто: накосячил - не собралось.
Так статические анализаторы полностью заменяют/реализуют это поведение, т.к. и реализуют компилятор по факту. Тот же вывод типов, то же построение CFG, всякие анализы DCE и проч. Лично я не могу представить, где бы наличие строгой типизации в языке решило бы проблему, которую не решают статанализаторы. Скорее наоборот, т.к. в PHP нет ни алгебраических типов (пользовательских имею ввиду), ни зависимых, ни шейпов, ни каких-либо более узких скаляров (class-string, non-empty-string, int<0, 2>, etc), ни чего-то ещё. Плюс taint-анализ...
А пример можно привести косяков статанализа? Потому что что-то не могу такого представить.
А IDE... Ну IDE (если мы говорим про PHPStorm) довольно примитивный анализ реализует. Да и в CI не воткнуть её в отличие от PHPStan/Psalm.
Ну просто взялся классический монолит и от него запилился сервис с отдельной бизнес-логикой на PHP 8.3 + Symfony 7.1 (изначально 6.4) с Доктриной, JMS, DDD, гекасгоналкой и прочим. Ну т.е. дефолтный стек вообще весь. В качестве аналогии по коду/архитектуре могу привести в пример вот эту репку с наброском сервиса https://github.com/SerafimArts/packagist.app/tree/master/app
Единственный "тюнинг" - это просто вместо FPM установлен RR (благо в симфе любой сервер 1 кнопкой меняется), да и то не для скорости, а просто чтобы весь сервис в один контейнер можно было собрать (ради удобства деплоя), вместо двух nginx+fpm.
Т.е. рефакторинг выглядел как рефакторинг, а скорость - просто сайд-эффект. Случайно получилось.
Увы, я других примеров не знаю, где бы реально оценивалась стоимость поддержки 1 монолита на PHP до и 1000 микросервисов на Go после (железо + человеческие ресурсы). И желательно без переписывания всего кода, а копирование предметной области 1 в 1.
Так что я могу ориентироваться лишь по косвенным докладам подобным и собственным опытом.
P.S. Было бы неплохо услышать доклад/статью про "мы переехали с Go на PHP и вот что получилось". Вангую, там бы тоже получили ускорение и удешевление.
Это если переменные в каком-нибудь локальном скоупе, тогда думаю да. Но это скорее оптимизации процесса всё же. То что компилятор эффективнее оптимизирует потребление памяти на работу внутри функции - это, думаю, скорее всего очевидно (хотя есть конечно приёмы, требующие JIT с рантаймом).
Но код на Go в основном пишется не в функциональном стиле, а наличие структур уже говорит о каком-то стейте. А стейт придётся и так и так хранить где-то, в отличие от PHP, у которого в большинстве случаев стейта нет, а всё что он может хранить - это байткод в mmap/sysv.
P.S. Под эффективностью менеджмента я имел ввиду утилизацию в ноль, т.к. в GC у пыха вообще дефрагментации нет, например, о какой эффективности (кроме скорости работы) можно говорить.
Неа. Достаточно while с continue и со сменой стейта. А peg или parser-combinator вообще даже без continue можно. Последний вообще через рекурсию, тупо с новыми аргументами (которые опять же можно развернуть в обычный while с массивом/вектором из стека).
Короче, goto не нужен. Только если хочется сделать одну километровую говнокодистую портянку сразу со всеми видами состояний, да и то спорно.
Ну т.е. у вас всё своё, нет ни единой библиотеки на PHP из композера, т.к. сам композер не работает, но при этом "это чуть-чуть другой рантайм", я правильно понял?)))
P.S. И с каких пор конструкции, полностью поддерживающиеся IDE, с работой автокомплита, с покрытием стат.анализатором, без каких либо инструментов метапрограммирования (get/set/call) и прочим называется "магией"?
А теперь, финт ушами. Языком PHP может называться язык, соответствующий спецификации PHP (1) https://phplang.org/ и (2) https://github.com/php/php-langspec
Откройте, например, часть про выражения: https://github.com/php/php-langspec/blob/master/spec/10-expressions.md и скажите, KPHP всё поддерживает? Даже eval? Если нет, то о чём речь? Это не PHP и не является им. Это не "другой рантайм". Это лишь диалект/подмножество.
А другой рантайм - это вот: https://github.com/ircmaxell/php-llvm легковесный бекенд поверх llvm.
А у вас приложение на Symfony, Laravel, Laminas или может быть Slim с Doctrine? Или всё же "просто другой рантайм" оказался не таким уж и "простым" и всё пришлось написать с нуля, т.к. язык всё же другой с похожим синтаксисом, верно?
P.S. У меня позиция, что для быстрых приложений достаточно воткнуть Swoole/RoadRunner/etc, а менять его на какой-нибудь Rust/C/Go уже только в случае критически важных секций, коих на практике оказывается обычно ровно 0.
В любом случае это не PHP, а лишь подобие с похожим синтаксисом.
Есть подозрение что пытаются, однако чтоб сделать адекватно что-то -- нужно половину фреймворка перелопатить и написать с нуля...
Чем хуже конкретно данный валидатор?
Да дофига чем:
Атрибуты, которые семантически должны представлять из себя классы метадаты отвечают ещё за валидацию. Смешение логики и правил маппингов.
В примерах кода не вижу вообще возможностей вынести правила валидации отдельно от DTO, например в yaml, php, json, etc. Чтобы правила можно было указывать во внешних файлах и изолировать от DTO.
Не вижу зависимых правил и сложных выражений, типа
When X then (Y or Z). И даже реализовать подобное невозможно, кажется, учитывая то что в правила валидации приходит значение только одного поля.Способа внедрить в конструктор в валидаторы тоже не вижу, т.к. см. п.1. Ну типа есть, например, сервис, предоставляющий анализ текста на "мат", как его всунуть в валидатор, чтоб сказать:
#[DoesNotContainSwearWords(criteria: 0.2)], который уже делегируется нужному валидатору, который содержит инфу и локализации, и нужные коннекты к сервису и прочее.Контекста и прочей инфы тоже нет, т.к. см. п.1
А в виде пакета как это поставить и посмотреть? Ну вот я хочу использовать у себя этот пакет отдельно в проекте, например...
Могу ещё накидать чем это хуже)
Ну т.е. если сравнивать с типичным кодом Битрикса, то это огромный шаг вперёд и выглядит на первый взгляд даже годно. Тут можно только поздравить, что у разработчиков наконец удалось написать код, от которого не хочется сразу вырвать себе глаза. Но это касается исключительно неймспейса
Bitrix\Main\Validation\Xxx...А если же сравнивать с тем же Symfony, то, например у меня, сразу возникает такой же вопрос "зачем": Т.к. фактически это копипаста существующего решения, но с худшей реализацией и наличием критичных (в т.ч. архитектурных) косяков, которые не позволяют нормально использовать этот компонент. Ну помимо того, что использовать его просто невозможно ввиду отсутствия в пакагисте)))
Отсюда, с точки зрения здравого смысла и этот вопрос: Зачем делать то, что и так существует, только архитектурно неправильно и в целом хуже? И варианта кроме как "потому что могут" тут, боюсь что нет.
А можно для немного тупеньких. Вот вы говорите про какие-то экспортные ограничения...
Если JB ушли с рынка РФ и ликвидировали юр.лицо, то разве это не означает, что не существует того, кто мог бы проконтролировать и предъявить за использование инструментов JB? Т.к. де-юре их (этих товаров) на территории РФ не существует, а значит и фактическая лицензия недействительна, следовательно и использовать можно без каких-либо ограничений.
Я не юрист, если что, просто интересно как упомянутые, цитата "экспортные ограничения", которых нет на территории РФ действуют на частное лицо на этой территории и почему это незаконно, как вы описываете.
Раунд!
Надо сажать не студентов, а профи в симфе и профи в ларе и дать им задачу запилить какое-либо ПО максимально всрато и в максимально сжатые сроки.
Ну, например, какой-нибудь сервис логина и регистрации акков с поддержкой OTLP мониторинга на уровне БД. И HTTP АПИ наружу, запрос-ответ, в каком-нибудь msgpack формате.
Чтобы модели ёлки кастовать в энтити можно взять JMS или Symfony Serializer. С другой стороны и троллейбус из хлеба можно сделать...
Ну и всё же это не столько "чистая архитектура", сколько конкретная репрезентация в виде гексагоналки. Хотя не спорю что что-то адекватнее или какую-либо альтернативу сложно придумать.
Я понял, я просто пояснил что я подразумевал под "фигак-фигак".
Этот "фигак-фигак" можно рассматривать как требования к разработке сервиса свыше от манагеров. Мол, "надо чтобы было сделано уже вчера". Это о чём я говорю.
А то о чём ты говоришь, "фигак-фигак" -- это не требования к ПО, а возможности разработчика, когда он кроме такого пути ничего просто не умеет.
RR и Swoole принципиально разные инструменты для совершенно разных задач. Одно тупо альтернатива FPM почти 1 в 1 с такой же однопоточной и блокирующей работой, а другое набор инструментов для написания асинхронных и многопоточных приложений, где просто есть в наличии API для работы с HTTP. Но не будем об этом...
Да, RR -- RoadRunner, просто полноценно живущий CGI, причём не самый быстрый, прошу заметить. Его преимущество только в том, что можно взять FPM и заменить на RR без каких-либо доработок и наоборот.
Но на всякий случай повторюсь, не используя всяких глобальных переменных, всяких статических шляп, синглтонов и прочего, ну т.е. запиливая обыкновенный адекватный код уровня миддла - рантаймы можно как перчатки менять. Примерно такие же правила хорошего тона, как "не завязываться на Apache". Вроде не рокет сайнс.
Ну всё же нет. Студент симфу не осилит просто, по-моему. А "фигак-фигак" вполне может быть техническим требованием к продукту.
Получаем "тщательно выписанные энтити" vs "тщательно выписанные миграции". В ларке даже тут писанины больше, т.к. написать энтитю из которой сами миграции сгенерятся проще и быстрее, нежели вначале ап миграции, потом откат миграции, а потом ещё модель.
В симфе так же можно фигануть
App\: { resource: "path/to/app" }и забыть про конфиги сервисов, сделав вид, что оно работает так же как в ларке. Ну да, тут побольше писанины на одну строчку!Я же и говорю, при должном желании и компетенциях -- на симфе, имхо, почти всё получается быстрее, даже говнокод)
Поэтому и считаю что "фигак-фигак" и "вчерашний студент" - разные вещи, т.к. чтобы на симфе максимально лаконично и быстро что-то наклепать -- как минимум требуется знать где именно можно сократить что.
Не соглашусь (ну точнее не полностью). Имхо, основное преимущество Laravel в человеческих ресурсах, когда берёшь вчерашнего студента, сажаешь его на Laravel и вуаля, на выходе даже что-то работает. И там не то что фреймворк не обязательно знать, но и на PHP зачастую пофигу.
Ну потому что "фигак-фигак и в прод" можно и на симфе делать, и местами даже быстрее. Однако всё же квалификация под симфу требуется повыше.
https://github.com/joomla/joomla-cms/blob/5.2-dev/composer.json ?
А это, простите, что за стандарт такой?)
Так статические анализаторы полностью заменяют/реализуют это поведение, т.к. и реализуют компилятор по факту. Тот же вывод типов, то же построение CFG, всякие анализы DCE и проч. Лично я не могу представить, где бы наличие строгой типизации в языке решило бы проблему, которую не решают статанализаторы. Скорее наоборот, т.к. в PHP нет ни алгебраических типов (пользовательских имею ввиду), ни зависимых, ни шейпов, ни каких-либо более узких скаляров (class-string, non-empty-string, int<0, 2>, etc), ни чего-то ещё. Плюс taint-анализ...
А пример можно привести косяков статанализа? Потому что что-то не могу такого представить.
А IDE... Ну IDE (если мы говорим про PHPStorm) довольно примитивный анализ реализует. Да и в CI не воткнуть её в отличие от PHPStan/Psalm.
Ну это плохой код. Обычно, разработчики миддл+ и выше так не пишут, как минимум потому что статический анализатор такое не пропустит.
Ну просто взялся классический монолит и от него запилился сервис с отдельной бизнес-логикой на PHP 8.3 + Symfony 7.1 (изначально 6.4) с Доктриной, JMS, DDD, гекасгоналкой и прочим. Ну т.е. дефолтный стек вообще весь. В качестве аналогии по коду/архитектуре могу привести в пример вот эту репку с наброском сервиса https://github.com/SerafimArts/packagist.app/tree/master/app
Единственный "тюнинг" - это просто вместо FPM установлен RR (благо в симфе любой сервер 1 кнопкой меняется), да и то не для скорости, а просто чтобы весь сервис в один контейнер можно было собрать (ради удобства деплоя), вместо двух nginx+fpm.
Т.е. рефакторинг выглядел как рефакторинг, а скорость - просто сайд-эффект. Случайно получилось.
Увы, я других примеров не знаю, где бы реально оценивалась стоимость поддержки 1 монолита на PHP до и 1000 микросервисов на Go после (железо + человеческие ресурсы). И желательно без переписывания всего кода, а копирование предметной области 1 в 1.
Так что я могу ориентироваться лишь по косвенным докладам подобным и собственным опытом.
P.S. Было бы неплохо услышать доклад/статью про "мы переехали с Go на PHP и вот что получилось". Вангую, там бы тоже получили ускорение и удешевление.
Это если переменные в каком-нибудь локальном скоупе, тогда думаю да. Но это скорее оптимизации процесса всё же. То что компилятор эффективнее оптимизирует потребление памяти на работу внутри функции - это, думаю, скорее всего очевидно (хотя есть конечно приёмы, требующие JIT с рантаймом).
Но код на Go в основном пишется не в функциональном стиле, а наличие структур уже говорит о каком-то стейте. А стейт придётся и так и так хранить где-то, в отличие от PHP, у которого в большинстве случаев стейта нет, а всё что он может хранить - это байткод в mmap/sysv.
P.S. Под эффективностью менеджмента я имел ввиду утилизацию в ноль, т.к. в GC у пыха вообще дефрагментации нет, например, о какой эффективности (кроме скорости работы) можно говорить.