Telegram Web Link
Как изощрённо очистить свойство после чтения

Встретил в коде Symfony альтернативное решение задачи из старого поста.

Пишите в комментариях, пропустили ли бы вы такой код на ревью и почему. 🤓

/**
* @return list<object>
*/
public function releaseEvents(): array
{
try {
return $this->events;
} finally {
$this->events = [];
}
}
Please open Telegram to view this post
VIEW IN TELEGRAM
Если вы используете Deployer, то после успешного пятничного деплоя можете поиграть в Блэкджек из консоли.

./vendor/bin/dep blackjack
Podlodka PHP Crew

Думаю, все вы слышали про однонедельные интенсивы от авторов известного подкаста Podlodka. Так вот, 31-ого октября стартует первая Podlodka PHP Crew!

Тема этого сезона — архитектура (антипаттерны, best practices, DDD, API, события). Среди докладчиков Александр Макаров, Антон Титов, Дмитрий Елисеев, Павел Лакосников и другие пыхари из Skyeng, ManyChat и Тинькофф.

Подробности на сайте, там же скоро финализируют расписание. Покупать билеты лучше сейчас — скидки действуют только до следующего понедельника!
Пых
Continuous Integration CI — must have для проекта любого размера. CI повышает качество кодовой базы, дисциплинирует команду и сокращает количество и продолжительность ревью. Идеи проверок на базе нашего пайплайна в Happy Inc.: • кодстайл (PHP CS Fixer, …
Continuous Integration Tools 2.0

Почти полтора года назад я выложил пост с основными идеями для CI-пайплайна проекта на PHP. С тех пор не так много изменилось, разве что Rector стабилизировался и для многих стал инструментом рефакторинга номер один, а в Composer появился встроенный анализ уязвимостей.

Представляю обновлённый список по категориям ("+" помечены новые пункты, через "/" перечислены альтернативы).

Рефакторинг
+ автоматический рефакторинг и актуализация кода (Rector),
• кодстайл (PHP CS Fixer / PHP_CodeSniffer / EasyCodingStandard),
• статический анализ (Psalm / PHPStan / PHPMD).

Пакеты
+ проверка на уязвимости (composer audit),
• валидность composer.json (composer validate),
• явное требование задействованных пакетов (ComposerRequireChecker),
• отсутствие неиспользуемых пакетов (composer-unused).

Symfony Dependency Injection
+ собирабельность prod-контейнера (bin/console cache:clear --env=prod),
• проверка синтаксиса Yaml-файлов (bin/console lint:yaml config --parse-tags),
• проверка соответствия типов инъекций контейнера Symfony (bin/console lint:container),
• отсутствие устаревших сервисов и конфигов Symfony (bin/console debug:container --deprecations).

Twig
• проверка синтаксиса Twig-шаблонов (bin/console lint:twig).

Doctrine
• валидность маппинга и соответствие ему схемы БД (bin/console doctrine:schema:validate),
• корректность продакшн-конфигурации (bin/console doctrine:ensure-production-settings --env=prod).

Модули
• контроль связности/зацепления и направления зависимостей (Deptrac).

Ну и конечно же тесты
+ мутационное тестирование (Infection),
• сами тесты (PHPUnit / Codeception).

Список всё так же вдохновлён нашим пайплайном в HappyInc. Пишите в комментариях, без чего не обходится сборка вашего проекта и что ещё рекомендуете попробовать.

Также обратите внимание на репозиторий Static analysis tools for PHP и доклад 25+ инструментов для аудита кода.
🔴 Пыхэфир в эту субботу!

Дорогие пыхари, давненько мы с вами не виделись! В эту субботу у меня как раз будет время, чтобы это исправить.

Буду готов обсудить новости из мира PHP, прокомментировать чей-нибудь код, ответить на любые вопросы по PHP да и просто поговорить за жизнь. Пишите в комментариях, всё, что вам могло бы быть интересно.

Встречаемся в субботу в 17 на канале PHP Point. Если не будете онлайн, не переживайте, запись никуда не денется.

https://youtu.be/2UiGZVrNG6c
🔨 Первый в мире PHP-линч!

После нашей субботней встречи у меня появилась идея комментировать PHP-код на постоянной основе. Должно получиться пхплебно, зрелищно и очень познавательно!

Попробуем такой процесс:
1. Во время стрима вы скидываете в чат трансляции ссылки на репозитории и в трёх словах описываете, что там. Это может быть ваш пет-проект или библиотека, а может быть компонент (не)известного фреймворка. Заранее ссылки не принимаются.
2. Я выбираю проект по душе и клонирую репозиторий.
3. Комментирую на лету, говорю, что думаю, без обид.

Первый в мире PHP-линч пройдёт в эту среду в 18 часов на канале PHP Point. Запись обязательно будет.

https://youtu.be/MwMCzqvCGKo
Пых
🔨 Первый в мире PHP-линч! После нашей субботней встречи у меня появилась идея комментировать PHP-код на постоянной основе. Должно получиться пхплебно, зрелищно и очень познавательно! Попробуем такой процесс: 1. Во время стрима вы скидываете в чат трансляции…
🩸 Буквально через 5 минут начнётся первый в мире PHP-линч! 🎉

В честь дебюта проекта я разыграю два билета на Podlodka PHP Crew! Один из них вручу тому, кто скинет на ревью самый полезный и интересный проект. Второй билет получит наиболее активный участник чата трансляции. Подключайтесь!

https://youtu.be/MwMCzqvCGKo

Update. В трансляцию добавлены эпизоды, автору shoman4eg/moy-nalog и Alex D вручены билеты!
🎙 Пых в пятом выпуске CONSOLE.DIALOG

Мой друг и бывший коллега Алексей Соловьёв пригласил меня на подкаст CONSOLE.DIALOG, чтобы обсудить принятие решений в IT. Поговорили про путь в разработке, коммуникацию в идеальной компании и про то, как мы однажды в Happy Inc. всё переписали.

Получилось очень лампово, уверен, вы что-нибудь для себя почерпнёте. Большое спасибо, Лёш, за такую неожиданную тему!

Послушать можно где угодно, выбирайте: https://consoledialog.mave.digital/ep-5.

Подписывайтесь на @lyohajs в Telegram и Алексея Соловьёва в YouTube.
Please open Telegram to view this post
VIEW IN TELEGRAM
$reflectionPromotedProperty->hasDefaultValue()

final class A
{
public function __construct(
public string $a = 'default',
) {}
}
$property = new ReflectionProperty(A::class, 'a');
var_dump($property->hasDefaultValue()); // false

Довольно контринтуитивно, что этот код выведет false.

Однако если развернуть promoted свойство в обычное, станет понятно, почему:

final class A
{
public string $a;

public function __construct(
string $a = 'default',
) {
$this->a = $a;
}
}
$parameter = new ReflectionParameter([A::class, '__construct'], 'a');
var_dump($parameter->isDefaultValueAvailable()); // true

Дефолтное значение имеет не свойство, а параметр конструктора!
Как следствие, вот такой код

$class = new ReflectionClass(A::class);
$a = $class->newInstanceWithoutConstructor();
var_dump($a->a);

выбросит Typed property A::$a must not be accessed before initialization.

https://3v4l.org/kkf24
#[<T>] Дженерики через атрибуты

Роман Пронский в своём блоге предлагает реализовать стираемые дженерики путём расширения синтаксиса атрибутов.

Ход мысли такой. Сейчас мы описываем общие типы для Psalm и PHPStan в phpdoc-ах, то есть, по сути, и используем стираемые дженерики, только с не особо стандартизованным синтаксисом и в комментариях, КАРЛ. А ещё у нас есть атрибуты — синтаксис в PHP, предназначенный для метаинформации. Так почему бы нам не объединить две эти вещи? Так как атрибуты в текущем виде слабо подходят для типизации, Рома предлагает расширить их синтаксис, в частности, разрешить ставить атрибуты над выражениями и перед типом возвращаемого значения.

https://pronskiy.com/blog/generics-via-attributes-in-php/

Я считаю, что это интересный альтернативный взгляд на дженерики в PHP, но с ним связано несколько проблем:

1. Нарушение принципа единой отвественности для атрибутов. Мы либо получим неоднозначность в определении понятия "атрибут", либо просто дженерики с похожим синтаксисом.

2. Инстанциированные атрибуты можно получить только через рефлексию. Рефлексия — это рантайм и автолоадинг. Статанализ же в идеале вообще не должен запускать анализируемый код. Именно поэтому появились такие проекты, как PHP Parser и Better Reflection. Если же обновлённые атрибуты будут использоваться только как синтаксис, то нет смысла их называть атрибутами.

3. Приведенную в статье декларацию атрибута-дженерика над выражением вообще не получится отрефлексировать, поскольку для выражений по определению невозможна рефлексия. Из-за этого синтаксис дженериков может быть реализован только на уровне языка.

Получается, что замаскированные под атрибуты дженерики технически не смогут ими быть. Ну а в таком случае проще реализовать стираемые дженерики с привычным синтаксисом array<string, object>. Если же по каким-то техническим причинам необходимо оборачивать декларации в #[], то пусть это просто будут дженерики с таким синтаксисом.

Что касается самой концепции стираемых дженериков, я её однозначно поддерживаю. Да, такой подход требует наличия внешнего анализатора, но взамен даёт стандартизированный синтаксис, нативный парсинг кода с дженериками и популяризацию обобщённого программирования среди PHP-разработчиков.

Я очень рад, что Рома в очередной раз подогрел дискуссию вокруг дженериков. Любой подобный движ полезен для сообщества и приближает нас к результату.
Сколько, по вашему мнению, я, Валентин, стою как PHP-разработчик и тимлид в рублях в месяц?
Anonymous Poll
15%
200к
8%
250к
16%
300к
17%
350к
15%
400к
8%
450к
21%
БОЛЬШЕ!!!
Forwarded from PHP Russia Channel
ID-баттл: UUID vs автоинкремент обсудим с Валентином Удальцовым

📋 https://bx.vc/ek7oa2

Почти восемь лет, занимаясь разработкой веб-приложений, Валентин использовал для идентификации исключительно автоинкременты. И только 3,5 года назад он попробовал UUID в одном пет-проекте. С тех пор он и его команда в Happy Inc. почти всегда выбирают UUID для идентификации чего бы то ни было. Они научились коррелировать сущности разных модулей по идентификатору, пользоваться преимуществами разных типов UUID, одними из первых внедрили UUID v6.

Валентин обобщит опыт его команды и разложит по полочкам все “за” и “против” использования UUID и автоинкрементов в PHP-приложении. Обсудим актуальные способы генерации и хранения идентификаторов, изучим бенчмарки для разных сценариев и баз данных и подведём новую черту с пометкой "2022" под этим старым добрым холиваром.

Встречаемся 24 и 25 ноября на PHP Russia 2022, которая пройдет в рамках HighLoad++ 2022 🖐

Программа конференции и билеты здесь - https://bx.vc/ca1xqj
Функция json_encode чистая?
Anonymous Quiz
51%
Да
49%
Нет
Варварский генератор

Недавно с коллегами обсудили, что, строго говоря, генератор не соблюдает принцип подстановки Барбары Лисков. Он кидает исключение при попытке перемотки после начала обхода и тем самым нарушает контракт Iterable, где такое поведение не предусмотрено.

Понятно, почему конструктивно так сделали. Тем не менее передача генератора в функцию, которая принимает Traversable или iterable, приводит к WTF казусу, если она вполне законно пытается обойти аргумент больше одного раза.

Если очень хочется, чтобы инстанс генератора отрабатывал многократно, и при этом вы уверены, что это не приведёт к ненужным побочным эффектам, можно обернуть функцию, порождающую генератор, в RewindableGenerator:

/**
* @template TKey
* @template TValue
* @implements IteratorAggregate<TKey, TValue>
*/
final class RewindableGenerator implements IteratorAggregate
{
/**
* @param callable(): Generator<TKey, TValue> $generatorFunction
*/
public function __construct(private $generatorFunction) {}

public function getIterator(): Traversable
{
return ($this->generatorFunction)();
}
}

Вот как это будет работать: https://3v4l.org/46Evq.

Пишите в комментариях, где ещё PHP нарушает LSP.
Релиз PHP 8.2 откладывается на 2 недели до 8 декабря из-за найденных в последний момент критических багов. Подробности: https://externals.io/message/118991

— Nov 24: PHP 8.2.0RC7
— Dec 8: PHP 8.2.0
— Dec 15: PHP 8.2.1RC1
— Jan 5: PHP 8.2.1 (in sync with 8.0/8.1)
Сегодня PHP-линч, к сожалению, отменяется. Если буду успевать, встретимся на неделе. Если нет, то в следующую среду. Хорошего вечера!
2025/07/04 23:11:47
Back to Top
HTML Embed Code: