PHP 1555 ~ 1 мин.

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

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 разделено между лагерями статического и не статического анализа, и я не знаю, найдется ли когда-нибудь кто-то, кто сможет унифицировать и направить язык в нужное русло.

Что думаешь?

Категории
  • PHP 65
  • Заметки 15
  • Безопасность 3
  • Флуд 2
  • Nginx 2
  • ИТ новости 2
  • Видео 1
  • Docker 1
  • Roadmap 1
  • Архитектура 0

Хочешь поддержать сайт?

Делаем из мухи слона

sergeymukhin.com

персональный блог о веб-разработке от Сергея Мухина. Блог был основан в 2018 году, и собирался уделять основное внимание последним тенденциям, учебным пособиям, а также советам и рекомендациям, позволяющим начинающим девелоперам встать быстрее на правильную дорогу веб разработки, но что-то пошло не так 😃

Релизы PHP 8.4

Дата Релиз
8 Июня 2024 Альфа 1
20 Июня 2024 Альфа 2
04 Июля 2024 Альфа 3
16 Июля 2024 Feature freeze
18 Июля 2024 Бета 1
01 Августа 2024 Бета 2
15 Августа 2024 Бета 3
29 Августа 2024 RC 1
12 Сентября 2024 RC 2
26 Сентября 2024 RC 3
10 Октября 2024 RC 4
24 Октября 2024 RC 5
07 Ноября 2024 RC 6
21 Ноября 2024 GA

Что нового?