#[Override] в PHP 8.3

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

Почему это важно? Вы уже знаете, что переопределяете метод, не так ли? Что ж, давайте представим два класса:

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

final class Child extends Parent
{
    #[Override]
    public function methodWithDefaultImplementation(): void
    {
        return 2; // Переопределённый метод
    }
}

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

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

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

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

Несколько мыслей

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

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

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

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