Пых
8.34K subscribers
182 photos
10 videos
4 files
475 links
Блог @vudaltsov о разработке на PHP.

Хобот: @phpyhobot
YouTube: https://youtube.com/@phpyh
VK Видео: https://vkvideo.ru/@phpyh
Мемы: https://t.me/isPHPdying
Статистика: https://t.me/INOTAROBOT?start=st1219340804

Реклама и вакансии НЕ размещаются.
Download Telegram
Annotated Monthly c Ромой

Если вы, как и я, соскучились по Роме, то можете посмотреть стримы PHP Annotated с его участием.

https://youtu.be/v5VtCWgDebw
https://youtu.be/Dx4knBnuJaw
<?php

fclose(STDIN);
var_dump(is_resource(STDIN));
Маппинг входящих данных на аргументы action-ов

Наконец-то в 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
👨‍🔬 Новая лекция от Пыха. LRU мемоизация. Часть 2. Из O(n) в O(1)

Наконец-то записал вторую лекцию про LRU мемоизацию! Из неё вы узнаете, какая структура данных позволит нам получить решение с алгоритмической сложностью O(1) и как её построить самому. По дороге, как обычно, касаюсь ещё нескольких интересных мелочей.

https://boosty.to/phpyh/posts/64ce92fa-836d-4b5b-9035-c28074c13e3c
🎮 DatsArt Space

Мои хорошие друзья 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/
Пых
🔴 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
Как в рантайме получить путь до текущего автолоадера?

Сейчас работаю над 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 в комментариях к посту рассказал про метод ClassLoader::getRegisteredLoaders(), который возвращает массив активных лоадеров, проиндексированных по пути до vendor. А это ровно то, что мне было нужно!

Теперь локатор и тест тривиальные: https://gist.github.com/vudaltsov/c7348a8aa54d0ada82c22134c6156001. ComposerClassLocator покроет 95% случаев подгрузки пользовательских классов. В остальных 5% можно будет имплементировать свой локатор и через компоновщик объединить с другими.

Спасибо огромное за то, что вы всегда так внимательно читаете посты и пишете кучу полезных комментариев! 💙
Please open Telegram to view this post
VIEW IN TELEGRAM
<?php

namespace A;

echo namespace\B\C::class;
🌿 Про атрибут Override в PHP 8.3

В 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 👀