PHP 8.3: Атрибут #[Override]

В PHP 8.3 появился новый атрибут #[Override]. Он уже известен в других языках, но позвольте мне рассказать, для чего он нужен, если вы не знаете.

Пометка метода атрибутом #[Override] означает, что вы знаете, что этот метод переопределяет родительский метод. Вот в принципе и единственно все, что он делает, это показывает ваше намерение.

abstract class Parent
{
    public function methodWithDefaultImplementation(): int
    {
        return 1;
    }
}

final class Child extends Parent
{
    #[Override]
    public function methodWithDefaultImplementation(): void
    {
        return 2; // The overridden method
    }
} 

Теперь когда в какой-то момент родительский метод меняет имя своего метода:

abstract class Parent
{
    public function methodWithNewImplementation(): int
    {
        return 1;
    }
}

До атрибута не было способа узнать, что он больше не переопределяет переименованный метод Child::methodWithDefaultImplementation(), что могло привести к непредвиденным ошибкам.

Однако благодаря этому атрибуту PHP теперь знает, что что-то не так. По сути, он говорит: "Я знаю, что этот метод должен переопределять родительский метод. Если это когда-либо изменится, сообщите мне об этом".

Насколько это полезно?

Что, конечно больше всего, огорчает в этом RFC, так это то, насколько неуместным он может быть. Мы снова добавляем проверки во время выполнения, что может быть определено статическими анализаторами.

В телеграм чате PHP уже обсудили, что RFC практически бесполезен, да и в том же списке рассылки Extrernal многие люди пытались привести тот же аргумент об этом RFC, но безрезультатно. Я не буду повторять каждый аргумент, который приводился против, поэтому просто сошлюсь на предыдущие мысли по этой теме и резюмирую: "Юра, прости, мы все ... упустили". Внутренние компоненты PHP должны поставляться либо с официальной спецификацией для статических анализаторов, либо с собственным статическим анализатором. Почему? Потому что было бы возможно гораздо больше, и это бы значительно продвинуло PHP вперед.

Я не возражаю против этой функции, хотя сам, вероятно, никогда не буду ее использовать (я использую IDE, которая предотвращает подобные ошибки, мне не нужна среда выполнения PHP, чтобы перепроверить ее для меня). Что меня огорчает, так это то, как сообщество PHP разделено между лагерями статического и не статического анализа, и я не знаю, найдется ли когда-нибудь кто-то, кто сможет унифицировать и направить язык в нужное русло.