Контекст в PSR-3 Logger

Периодически сталкиваюсь с неправильным использованием $context в PSR логгере. Давайте вместе внимательно перечитаем стандарт.

1.3.1 Every method accepts an array as context data. This is meant to hold any extraneous information that does not fit well in a string. The array can contain anything. Implementors MUST ensure they treat context data with as much lenience as possible. A given value in the context MUST NOT throw an exception nor raise any php error, warning or notice.

Жирным выделил то, что многие упускают: вы можете передавать в контекст абсолютно любые значения, в том числе массивы, объекты, замыкания и ресурсы. Не нужно самостоятельно проводить нормализацию. По стандарту это задача логгера, а не ваша. Вот как, например, Monolog обработает контекст со сложными элементами:

$logger = new Monolog\Logger(
    name: 'app',
    handlers: [new Monolog\Handler\StreamHandler(STDOUT)],
    processors: [new Monolog\Processor\PsrLogMessageProcessor()]
);

final readonly class Foo
{
    public function __construct(
        public string $public = 'bar',
        private string $private = 'baz',
    ) {}
}

$logger->debug('Message', [
    'birthday' => new DateTimeImmutable('06.04.2019'),
    'object' => new Foo(),
    'closure' => static fn (): int => 1,
    'resource' => STDIN,
]);

[2024-09-27T13:02:16.303651+00:00] app.DEBUG: Message {"birthday":"2019-04-06T00:00:00+00:00","object":{"Foo":{"public":"bar"}},"closure":{"Closure":[]},"resource":"[resource(stream)]"} []

1.3.2 If an Exception object is passed in the context data, it MUST be in the 'exception' key. Logging exceptions is a common pattern and this allows implementors to extract a stack trace from the exception when the log backend supports it. Implementors MUST still verify that the 'exception' key is actually an Exception before using it as such, as it MAY contain anything.

Исключения нужно добавлять в контекст с ключом 'exception'. Никогда не раскладывайте объект исключения на массив вида ['message' => $e->getMessage(), 'line' => $e->getLine(), ...] — так вы не даёте процессорам и форматтерам самим принять решение относительно состава лога исключения и глубины его нормализации.

$logger->critical('Oops!', [
    'exception' => new LogicException(
        message: 'Level 2',
        previous: new RuntimeException('Level 1'),
    ),
]);

[2024-09-27T13:14:04.880133+00:00] app.CRITICAL: Oops! {"exception":"[object] (LogicException(code: 0): Level 1 at test.php:27)\n[previous exception] [object] (RuntimeException(code: 0): Level 2 at test.php:29)"} []

1.2.2 The message MAY contain placeholders which implementors MAY replace with values from the context array.
Placeholder names MUST correspond to keys in the context array.
Placeholder names MUST be delimited with a single opening brace { and a single closing brace }.
Placeholder names SHOULD be composed only of the characters A-Z, a-z, 0-9, underscore _, and period .. The use of other characters is reserved for future modifications of the placeholders specification.
Users SHOULD NOT pre-escape placeholder values since they can not know in which context the data will be displayed.

Ну и конечно же не забывайте про плейсхолдеры в сообщении. Вместо интерполяции и sprintf куда удобнее писать так:

$logger->notice('Process {pid} started at {time}', [
    'pid' => getmypid(),
    'time' => new DateTimeImmutable(),
]);

[2024-09-27T13:23:29.306682+00:00] app.NOTICE: Process 45104 started at 2024-09-27T13:23:29.306681+00:00 {"pid":45104,"time":"2024-09-27T13:23:29+00:00"} []

В последний момент исправляю рефлексию в PHP 8.4!

На неделе я начал добавлять поддержку PHP 8.4 в Typhoon Reflection, и очень рад, что взялся за это до релиза.

Во-первых, я зарепортил отсутствие обещанной в RFC хуков константы ReflectionProperty::IS_VIRTUAL. Но это тривиально, PR уже готов.

А вот что меня реально загрузило, так это поведение новых методов ReflectionProperty::isPrivateSet() и isProtectedSet() из Asymmetric Visibility RFC. Посудите сами:

final class Foo
{
    // isPrivateSet() = true 👌
    public private(set) mixed $public_private_set;

    // isPrivateSet() = false 🤯
    private private(set) mixed $private_private_set;

    // isPrivateSet() = false 🤯
    private mixed $private;

    // isProtectedSet() = true 👌
    public readonly mixed $public_readonly;

    // isProtectedSet() = false 🤯
    protected readonly mixed $protected_readonly;

    // isProtectedSet() = false 🤯
    protected protected(set) readonly mixed $protected_protected_set_readonly;

    // isPrivateSet() = false 👌, isProtectedSet() = false 👌
    public bool $virtual_no_set_hook { get => true; }
}

Сначала я подумал, что это баг, и создал тикет php-src#16175. Ilija, автор RFC, объяснил, почему так работает. Дело в том, что у свойств с симметричной видимостью отсутствует флаг ассиметричности. Поэтому для private и private private(set) isPrivateSet() возвращают false, а не true, как было бы логично ожидать. readonly свойства без явного (set) под капотом получают protected (set) (см. "Relationship with readonly" в RFC), поэтому public readonly будет ассиметричным с isProtectedSet() = true, а protected readonly — симметричным с isProtectedSet() = false.

Стало понятно, вот только пользоваться такой рефлексией по-прежнему дико неудобно. В API протекли детали реализации, которые, наоборот, должны быть инкапсулированы. Задача рефлексии — предоставить пользователю комфортный способ изучать код, а не продемонстрировать подкапотное устройство языка.

Но это ещё ладно. Сегодня до меня дошло, что в текущем виде рефлексия в PHP 8.4 ломает обратную совместимость! Если раньше проверка $reflectionProperty->isPublic() гарантировала, что не readonly свойства доступны на запись и чтение из глобального скоупа, то при текущей реализации в 8.4 она будет гарантировать только чтение!

$reflectionProperty = new ReflectionProperty($class, $property);

if ($reflectionProperty->isPublic() && !$reflectionProperty->isReadonly()) {
    $object->{$property} = $value;
}

Например, такой код корректно отработает для любых классов в PHP 8.3, но споткнётся на public private(set) $property в 8.4, потому что isPublic() вернёт true, а запись в свойство бросит ошибку.

Вот что я предложил в письме к internals, которое составил в Сапсане по дороге на Live PHP:

• ReflectionProperty::isPublic(), isProtected() и isPrivate() должны сохранить своё поведение и возвращать true только если свойство симметричное. Для public readonly метод будет возвращать false, потому что под капотом оно асимметричное с protected(set). Да, это сломает обратную совместимость, но не так критично, потому что все библиотеки уже учитывают тот факт, что в readonly нельзя писать из глобального скоупа.
• Добавить ReflectionProperty::isPublicGet(), isProtectedGet() и isPrivateGet(). Они должны возвращать true, если свойство симметрично или асимметрично доступно на чтение.
• Добавить ReflectionProperty::isPublicSet() и поменять поведение isProtectedSet() и isPrivateSet(): они должны возвращать true, если свойство симметрично или асимметрично доступно на запись.

Вся проблема в том, что недавно вышел PHP 8.4 RC1, и вносить изменения уже поздно. Надеюсь, что мой посыл про нарушение обратной совместимости всё-таки убедит сделать исключение.

Ну это, фартаны, известный прикол. А как вы думаете, почему такой код работает?

<?php

echo b'Пых';

https://3v4l.org/D40FF

Могу!

https://code.golf/golfers/vudaltsov/fizz-buzz/php/bytes

Следующая версия PHP — 8.5

Если кто-то вдруг, как и я, полагал, что четвёртый минорный релиз будет последним для PHP 8 (по аналогии с PHP 7), то это не так. В ноябре следующего года ожидается PHP 8.5. Насчёт 9.0 нет никакой информации.

Мне это вчера подсветил Рома Пронский. Пруфы в переписках internals и в свежих RFC:
▸ https://externals.io/message/125667
▸ https://wiki.php.net/rfc/deprecations_php_8_5