Annotated Monthly c Ромой
Если вы, как и я, соскучились по Роме, то можете посмотреть стримы PHP Annotated с его участием.
https://youtu.be/v5VtCWgDebw
https://youtu.be/Dx4knBnuJaw
Если вы, как и я, соскучились по Роме, то можете посмотреть стримы PHP Annotated с его участием.
https://youtu.be/v5VtCWgDebw
https://youtu.be/Dx4knBnuJaw
Маппинг входящих данных на аргументы action-ов
Наконец-то в Symfony это сделали! Теперь всякие RequestMappingBundle будут не нужны.
Предлагаю отлинчевать на следующей неделе.😉
https://symfony.com/blog/new-in-symfony-6-3-mapping-request-data-to-typed-objects
Наконец-то в Symfony это сделали! Теперь всякие RequestMappingBundle будут не нужны.
Предлагаю отлинчевать на следующей неделе.
use Symfony\Component\HttpKernel\Attribute\MapQueryString;
use Symfony\Component\HttpKernel\Attribute\MapRequestPayload;
final class Action
{
public function __invoke(
#[MapQueryString] MyQueryDataClass $query,
#[MapRequestPayload] MyPayloadDataClass $payload,
): Response {
// ...
}
}
https://symfony.com/blog/new-in-symfony-6-3-mapping-request-data-to-typed-objects
Please open Telegram to view this post
VIEW IN TELEGRAM
Symfony
New in Symfony 6.3: Mapping Request Data to Typed Objects (Symfony Blog)
Symfony 6.3 introduces two new PHP attributes to map the incoming request data into typed objects like DTOs and validates them automatically.
👨🔬 Новая лекция от Пыха. LRU мемоизация. Часть 2. Из O(n) в O(1)
Наконец-то записал вторую лекцию про LRU мемоизацию! Из неё вы узнаете, какая структура данных позволит нам получить решение с алгоритмической сложностью O(1) и как её построить самому. По дороге, как обычно, касаюсь ещё нескольких интересных мелочей.
https://boosty.to/phpyh/posts/64ce92fa-836d-4b5b-9035-c28074c13e3c
Наконец-то записал вторую лекцию про LRU мемоизацию! Из неё вы узнаете, какая структура данных позволит нам получить решение с алгоритмической сложностью O(1) и как её построить самому. По дороге, как обычно, касаюсь ещё нескольких интересных мелочей.
https://boosty.to/phpyh/posts/64ce92fa-836d-4b5b-9035-c28074c13e3c
Мои хорошие друзья DatsTeam организовали очередной хакатон, в котором командам предстоит написать «геймпад» к некой «игровой консоли» и сыграть при помощи него в игру. Условия хакатона не ограничивают участников в выборе технологий, поэтому среди участников есть и пыхари! Пожелаем им удачи!
Прямая трансляция стартует с минуты на минуту: https://youtu.be/OSDZVHsUSmE
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from samdark blog ☕️ (Alexander Makarov)
🔗 Awesome load balancing visualization
An interactive post by Sam Rose about load balancing basics. I ❤️ how it is visualized.
https://samwho.dev/load-balancing/
An interactive post by Sam Rose about load balancing basics. I ❤️ how it is visualized.
https://samwho.dev/load-balancing/
Пых
🔴 PHP-линч #14 Ты готов к линчу?! Тогда заходи! https://youtu.be/zaauoW2nimc
🔴 PHP-линч #15
Продолжаем обсуждать Symfony
https://youtu.be/lHXrYr134tw
Продолжаем обсуждать Symfony
#[MapRequestPayload]
, заходи!https://youtu.be/lHXrYr134tw
YouTube
PHP-линч #15 • Symfony #[MapRequestPayload], часть 2
0:00 Вступление, вспоминаем предыдущий стрим (https://youtu.be/zaauoW2nimc)
5:32 Откапываем интересующий нас код, ValueResolveInterface
8:56 Линч RequestPayloadValueResolver
35:00 Вопрос про кэш сериализатора и валдиатора
35:53 Новый reader mode для phpDoc…
5:32 Откапываем интересующий нас код, ValueResolveInterface
8:56 Линч RequestPayloadValueResolver
35:00 Вопрос про кэш сериализатора и валдиатора
35:53 Новый reader mode для phpDoc…
Пых
🔴 PHP-линч #15 Продолжаем обсуждать Symfony #[MapRequestPayload], заходи! https://youtu.be/lHXrYr134tw
Please open Telegram to view this post
VIEW IN TELEGRAM
🔴 PHP-линч #18
Сегодня на линче новый компонент Yii 3: Hydrator! Мне его на днях скинул Сергей Предводителев, член экипажа Yii. Кстати, подписывайтесь на его канал @sergei_predvoditelev.
По просьбам трудящихся пробуем стартовать позже, в 19. 😉
https://youtu.be/4_TVEgU3rpM
Сегодня на линче новый компонент Yii 3: Hydrator! Мне его на днях скинул Сергей Предводителев, член экипажа Yii. Кстати, подписывайтесь на его канал @sergei_predvoditelev.
По просьбам трудящихся пробуем стартовать позже, в 19. 😉
https://youtu.be/4_TVEgU3rpM
YouTube
PHP-линч #18
Внимание! Чтобы YouTube опубликовал ваш комментарий, пишите не полный URL, а, например, гитхаб/symfony/console.
Как устроен PHP-линч:
1. Во время стрима вы скидываете в чат трансляции ссылки на репозитории и в трёх словах описываете, что там. Это может быть…
Как устроен PHP-линч:
1. Во время стрима вы скидываете в чат трансляции ссылки на репозитории и в трёх словах описываете, что там. Это может быть…
Как в рантайме получить путь до текущего автолоадера?
Сейчас работаю над PHP Extended Type System, и появилась задача использовать автолоадер Composer для получения файлов незагруженных классов по их имени. При этом хочется, чтобы по умолчанию пользователю библиотеки не надо было явно указывать путь до
Первое, что приходит в голову, — просчитать и захардкодить путь. Например, если у нас пакет называется
Теперь попробуем покрыть это тестом. Первый вариант — засимлинкать текущий автолоадер в нужную локацию и инстанциировать локатор. Получим максимально дурацкий и хрупкий тест, да ещё и выйдем за пределы рабочей директории. Второй вариант — честно установить либу в отдельной папке с использованием репозитория type: path, symlink: false и инстанциировать локатор там. Вот только запускать это всё придётся в отдельном процессе, иначе копия класса будет конфликтовать с исходником в пространстве имён. Короче, сложно и тоже хрупко.
Поэтому я ещё почесал репу и придумал, как вообще отвязаться от расположения класса локатора:
То есть мы через рефлексию получаем путь к генерируемому композером классу
При втором подходе локатор устойчив к перемещению и легко тестируется с текущим автолоадером.
Сейчас работаю над PHP Extended Type System, и появилась задача использовать автолоадер Composer для получения файлов незагруженных классов по их имени. При этом хочется, чтобы по умолчанию пользователю библиотеки не надо было явно указывать путь до
autoload.php
. Библиотека должна по возможности угадать его сама.Первое, что приходит в голову, — просчитать и захардкодить путь. Например, если у нас пакет называется
extended-type-system/type-reflection
, а класс локатора расположен в src/ClassLocator/ComposerAutoloadClassLocator.php
, то после установки библиотеки путь от класса до автолоадера будет __DIR__ . '/../../../../autoload.php'
.Теперь попробуем покрыть это тестом. Первый вариант — засимлинкать текущий автолоадер в нужную локацию и инстанциировать локатор. Получим максимально дурацкий и хрупкий тест, да ещё и выйдем за пределы рабочей директории. Второй вариант — честно установить либу в отдельной папке с использованием репозитория type: path, symlink: false и инстанциировать локатор там. Вот только запускать это всё придётся в отдельном процессе, иначе копия класса будет конфликтовать с исходником в пространстве имён. Короче, сложно и тоже хрупко.
Поэтому я ещё почесал репу и придумал, как вообще отвязаться от расположения класса локатора:
use Composer\Autoload\ClassLoader;
$classLoaderFile = (new \ReflectionClass(ClassLoader::class))->getFileName();
$autoloadFile = dirname($classLoaderFile, 2) . '/autoload.php';
$autoloader = require $autoloadFile;
То есть мы через рефлексию получаем путь к генерируемому композером классу
ClassLoader
(это, кстати, публичный контракт, на него можно смело положиться), а уровнем выше забираем наш autoload.php
.При втором подходе локатор устойчив к перемещению и легко тестируется с текущим автолоадером.
Пых
Как в рантайме получить путь до текущего автолоадера? Сейчас работаю над PHP Extended Type System, и появилась задача использовать автолоадер Composer для получения файлов незагруженных классов по их имени. При этом хочется, чтобы по умолчанию пользователю…
Всё гораздо проще!
Я так и чувствовал, что надо было написать пост не только чтобы поделиться, но и потому что я что-то упустил.
@xepozz в комментариях к посту рассказал про метод
Теперь локатор и тест тривиальные: https://gist.github.com/vudaltsov/c7348a8aa54d0ada82c22134c6156001.
Спасибо огромное за то, что вы всегда так внимательно читаете посты и пишете кучу полезных комментариев!💙
Я так и чувствовал, что надо было написать пост не только чтобы поделиться, но и потому что я что-то упустил.
@xepozz в комментариях к посту рассказал про метод
ClassLoader::getRegisteredLoaders()
, который возвращает массив активных лоадеров, проиндексированных по пути до vendor
. А это ровно то, что мне было нужно!Теперь локатор и тест тривиальные: https://gist.github.com/vudaltsov/c7348a8aa54d0ada82c22134c6156001.
ComposerClassLocator
покроет 95% случаев подгрузки пользовательских классов. В остальных 5% можно будет имплементировать свой локатор и через компоновщик объединить с другими.Спасибо огромное за то, что вы всегда так внимательно читаете посты и пишете кучу полезных комментариев!
Please open Telegram to view this post
VIEW IN TELEGRAM
Gist
ComposerClassLocator.php
GitHub Gist: instantly share code, notes, and snippets.
Forwarded from Сергей Предводителев
🌿 Про атрибут Override в PHP 8.3
В PHP предлагается добавить специальный атрибут
Появление этого атрибута не ломает обратную совместимость, так как его использование опционально и, если его убрать, то метод будет также как и сейчас переопределяться.
Всё идёт к тому, что RFC будет принят (на текущий момент 20 голосов за и 0 против) и мы увидим
Несмотря на то, что применение атрибута для переопределяющих методов опционально, мне кажется, что использовать его нужно всегда и, скорей всего, IDE и статические анализаторы будут предлагать это сделать.
При изучении и разработке кода
Возможно, стоит в будущем (PHP 9 или 10 😎) вообще сделать добавление атрибута
Но у этой идеи есть и противники. Интересные обсуждения развернулись на reddit и externals.io 👀
В PHP предлагается добавить специальный атрибут
#[Override]
, с помощью которого можно будет явно помечать методы, которые переопределяют методы из родительского класса. Например:class Parent {Если в классе
protected function run(): void {}
}
class Child extends Parent {
#[\Override]
public function run(): void {}
}
Parent
убрать метод run()
, то будет брошено исключение. Появление этого атрибута не ломает обратную совместимость, так как его использование опционально и, если его убрать, то метод будет также как и сейчас переопределяться.
Всё идёт к тому, что RFC будет принят (на текущий момент 20 голосов за и 0 против) и мы увидим
#[Override]
в PHP 8.3.Несмотря на то, что применение атрибута для переопределяющих методов опционально, мне кажется, что использовать его нужно всегда и, скорей всего, IDE и статические анализаторы будут предлагать это сделать.
При изучении и разработке кода
#[Override]
позволит сразу понимать, что этот метод переопределяет родительский, и сократит время на выявление ошибок.Возможно, стоит в будущем (PHP 9 или 10 😎) вообще сделать добавление атрибута
#[Override]
для переопределяющих методов обязательным. Отсутствие атрибута в этом случае будет гарантировать, что метод ничего не переопределяет.Но у этой идеи есть и противники. Интересные обсуждения развернулись на reddit и externals.io 👀