03.04.2022 12:54
AlexLeonov 23 4000 Источник

Дисклеймер: Нет, это не дайджест авторства Романа Пронского. К сожалению, у меня нет достоверной информации - будет ли выходить его дайджест далее.

Однако я взял на себя смелость временно продолжить дело Романа и написать новый дайджест за тот месяц, что прошел с выхода последнего.

Если Роман сможет и захочет далее продолжать свой дайджест - он сам решит, как использовать мой текст: взять в свой проект, как его часть или нет. На всякий случай я ставлю нумерацию дайджеста через дробь. Однако не претендуя при этом на продолжение оригинального проекта.

PHP

Вышли версии PHP 8.1.4, 8.0.17. Обновления в основном посвящены исправлению найденных багов.

RFC (Requests for Comments )

За прошедшее время было не так много событий вокруг RFC.

Allow null and false as stand-alone types

https://wiki.php.net/rfc/null-false-standalone-types

В этом RFC предлагается добавить в систему тайп-хинтинга PHP еще два типа: null и false. Данная возможность позволит писать примерно такой код:

class Foo {
    public null $nil = null;
    public function foo(null $v): null 
    { /* ... */ *}
}

// В стандартной библиотеке достаточно много функций, возвращающих int|false или string|false
// Например таких:
function strpos(string $haystack, string $needle, int $offset = 0): int|false
{ /* ... */ *}

На всякий случай предлагается запретить декларацию типа ?null - видимо, от греха подальше :)

В момент, когда писалась статья, RFC находился на голосовании. Однако его принятие не вызывает никаких вопросов - результат голосования составляет 38 голосов "за" и 0 (ноль, а не null!) "против".

Undefined Variable Error Promotion

https://wiki.php.net/rfc/undefined_variable_error_promotion

Очень интересное предложение, которое фактически сводится к запрету на использование не объявленных явно переменных в PHP.

Сейчас обращение к необъявленной ранее (например через операцию присваивания) переменной производит ошибку уровня E_WARNING, после чего значением переменной становится null, а код продолжает выполняться далее, со следующей строки.

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

В данном RFC предлагается заменить ошибку уровня E_WARNING на исключение класса Error. Голосование закончено, результат весьма предсказуем: 33 "за" и 8 "против", предложение будет реализовано в PHP 9.

Sealed Classes

https://wiki.php.net/rfc/sealed_classes

Новая возможность языка, появление которой, если предложение будет принято, возможно уже в PHP 8.2

Вкратце: возможность для классов (и интерфейсов) ограничивать список своих наследников (и реализаторов). Проще, наверное, показать на примерах:

sealed class Foo permits Bar 
{
  /* ... */
}

class Bar extends Foo
{
  /* обычное наследование, без особенностей */
}

class Baz extends Foo
{
  /* фатальная ошибка этапа компиляции, наследование не разрешено */
}
sealed interface HasPrice permits Product, Service 
{
  /* ... */
}

class Product implements HasPrice 
{
  /* реализация интерфейса разрешена */
}

class Service implements HasPrice
{
  /* реализация интерфейса разрешена */
}

class User implements HasPrice
{
  /* ошибка, реализация интерфейса не разрешена! */
}

Наряду с классами и интерфейсами возможностью разрешать своё использование предлагается наделить и трейты. Можно будет указать список классов, которым будет позволено включать в себя данный трейт.

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

Новости фреймворков

Symfony

Laravel

  • Представлен инструмент Translation Checker, позволяющий находить в вашем коде фразы, не покрытые переводами

  • Представлен пакет Telegraph, упрощающий работу с Telegram: создание ботов, работа с чатами, сообщениями и API Telegram

  • Вышел релиз инструмента Visit - клиент для просмотра HTTP-запросов и ответов в человеко-читаемом виде

  • Вышли версии Laravel 9.4, 9.5

Yii

Ввиду того, что сервис OpenCollective более недоступен в России, сообщество фреймворка открывает дополнительный сбор пожертвований в сервисе Boosty: https://boosty.to/yiisoft

Отмечается, что разработка фреймворка замедлится из-за резкого (примерно в 5 раз) сокращения сумм пожертвований.

Дополнительная информация может быть найдена здесь.

Инструменты и библиотеки

  • php-dry: библиотека для поиска дубликатов в вашем коде

  • sebastian/type: коллекция ValueObject-обёрток над нативными типами PHP

  • Laravel Optikey: пакет, позволяющий использовать первичные ключи типа UUID в Laravel

  • Image with text: библиотека, включающая в себя продвинутые возможности создания текста на изображениях.

Интересные статьи

Хабр

Другие источники

Подготовлено при активном участии сообщества телеграм-чата "PHP Russian Talks".

Замечания по текущему выпуску и предложения для следующего можете отправлять автору в личку или в указанный выше чат.

Комментарии (23)


  1. kirillbdev
    03.04.2022 15:03
    #24228395
    +3

    Очень бы хотелось уже видеть типизированные массивы, по типу:

    function foo(int[] $array): Foo[]

    Может кто в курсе, есть ли движения в этом направлении? По RFC нашел что-то похожее со статусом decline


    1. AlexLeonov Автор
      03.04.2022 15:11
      #24228409

      Пока такое возможно только при использовании статических анализаторов, например Psalm.


    1. karneds
      03.04.2022 18:40
      #24228791

      Пока обхожусь таким вариантом

      function foo(int ...$array)


      1. AlexLeonov Автор
        03.04.2022 18:46
        #24228797

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


        1. karneds
          03.04.2022 19:00
          #24228835

          Типизация в php в целом создаёт дополнительную нагрузку. Т.к. интерпретатору необходимо эти проверки осуществлять при исполнении


          1. AlexLeonov Автор
            03.04.2022 20:34
            #24229033
            -2

            Слово «интерпретатор» не очень корректное, в остальном, конечно же, вы правы.


  1. TsarS
    03.04.2022 15:40
    #24228445

    • PHPIDS: библиотека обнаружения атак на ваши веб-приложения

    А что там последние коммиты 9 лет назад?


    1. AlexLeonov Автор
      03.04.2022 15:47
      #24228461

      Ваша правда. Включил в дайджест, потому что она обсуждалась в PHP Weekly.

      Уберу.


  1. greenkey
    03.04.2022 16:28
    #24228553
    +2

    Top PHP Web Development Trends in 2022 - довольно спорная статья, утверждающая, что современные тренды в PHP это: использование версий 7.1 и 7.2 и фреймворков Laravel, CakePHP, CodeIgniter, Zend Framework.

    Хах, упомянуть ларавел и не отметить симфони - это, как минимум, странно


  1. eandr_67
    03.04.2022 22:02
    #24229191
    +1

    Вообще-то голосование по Sealed Classes уже закончилось и предложение отклонено — т.к. не набрало 2/3 голосов.


    1. AlexLeonov Автор
      03.04.2022 23:03
      #24229295
      +1

      Я не одним днем готовил этот текст, прошу прощения.


  1. SerafimArts
    04.04.2022 00:15
    #24229431
    +1

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

    Нужно 2/3 что б принять =( Так что скорее всего зареджектят.


    P.S. Ой, я слепой слоупок, выше коммент как раз про это. Оказывается уже голосование закончилось даже. Что ж, очень жаль. Придётся дальше покрывать все классы @internal и @psalm-internal


  1. arkamax
    04.04.2022 04:27
    #24229597
    +1

    А может кто-нибудь объяснить, зачем нужен тип возврата null? Другими словами, если принимаем или возвращаем только null, то зачем его вообще принимать или возвращать? При наследовании его невозможно будет переписать (ошибка наследования). Единственный вариант - комбинированные типы с null (и вот их как раз можно было бы сузить в случае возврата или расширить комбинированным типом для параметров), но для этого узкого кейса уже есть nullable types. Что я упустил?


    1. mihteh
      04.04.2022 09:24
      #24229959

      Тоже пока не понимаю полезности типа null, нужен пример из реальной практики где это хорошо зайдет


    1. eandr_67
      04.04.2022 10:19
      #24230089
      +3

      Nullable types — это когда значение либо единственного типа, либо null. А для тех случаев, когда значение может быть одного из нескольких типов или null, nullable types не применимы — необходимо явно прописывать null.

      Нельзя написать:

      ?string|array
      или
      ?string|?array

      Надо:
      string|array|null

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


      1. arkamax
        04.04.2022 17:36
        #24231875

        ОК, спасибо, согласен в случае комбинированных типов с двумя и более + null. Разве что такие варианты лично я обычно вижу как антипаттерн и чаще всего ищу альтернативы, но это уже вкусовщина, скорее.


  1. mepihin
    04.04.2022 13:08
    #24230751

    Зачем Sealed Classes? Кто объяснит их реальное применение, а то кажется, что это какая-то избыточная штука, которой почти никто не будет пользоваться. Я просто реально не понимаю, зачем запрещать реализации классов и ограничивать наследников...


  1. greenkey
    04.04.2022 13:10
    #24230753
    +1

    Symfony - убрали официальную документацию на русском языке.

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


    1. Flying
      04.04.2022 14:13
      #24231009
      +1

      Что-то есть, например, здесь, но её актуальность и полнота под большим вопросом.

      Собственно переводы и убрали потому что их очень сложно поддерживать в актуальном состоянии.

      Также для ознакомления с Symfony сейчас, вероятно, лучше рекомендовать книгу. Вариант на русском с сайта убрали, но он есть, например, здесь.


  1. pudovMaxim
    04.04.2022 22:21
    #24232725

    Похоже, в php опять откат адекватности или я чего-то не понимаю.

    Вроде только стали нормально типизировать по-человечески, и вот новый возвращаемый тип false. Чем им bool не угодил-то?


    1. eandr_67
      04.04.2022 22:48
      #24232787
      +1

      Например, стандартная функция strpos возвращает либо целочисленный индекс (если подстрока найдена), либо значение false (если не найдена) — значение true она не может вернуть ни при каких обстоятельствах. Таких функций в стандартной библиотеке много, да и в пользовательском коде такой подход нередко встречается. Так что указание того, что функция может вернуть не любое значение типа bool, а либо значение отличного от bool типа (нормальное завершение), либо false (действие не выполнено), безусловно улучшает надёжность и читабельность кода.


      1. pudovMaxim
        05.04.2022 20:26
        #24236223

        Ага, а можно указать, что функция возвращает 42 и ничто иное?

        Понимаю откуда ноги растут, но не понимаю зачем это нужно. Про null еще понять можно, это всё же своеобразный тип данных, но false - это же уже и есть данные, но никак не тип.


        1. SerafimArts
          05.04.2022 21:56
          #24236431

          но false — это же уже и есть данные, но никак не тип.

          Почему?


          Ну т.е. почему какой-нибудь кейс Red у enum Color { Red, Green, Blue } рассматривается как отдельный подтип типа Color, который в свою очередь уже enum, а вот enum bool { true, false } уже нет, например?)