Фото: Peter Kokot.

Подборка свежих новостей и материалов из мира PHP. Вышла третья бета PHP 8.1, Swiftmailer больше не будет поддерживаться, PHP-FIG обсуждает обновляемые стандарты PER. Для PHP 8.2 предложены два новых RFC: про удаление динамических свойств и перегрузку операторов. Также в выпуске порция полезных инструментов, статьи и видео.


Приятного чтения!



Новости


  • PHP 8.1 Beta 3


    Последняя бета в цикле. Следующим релизом станет RC 1, который ожидается 2 сентября.
  • PHP 8.0.10, PHP 7.4.23, PHP 7.3.30


    Секьюрити обновления актуальных веток.
  • Конец Swiftmailer


    В ноябре прекращается поддержка популярного пакета для отправки почты Swiftmailer. Вместо него будет развиваться symfony/mailer.

    Возможности и концепции Symfony Mailer повторяют Swiftmailer, поэтому миграция должна пройти достаточно легко. В Rector есть скрипт миграции и он всего лишь переименовывает классы.
  • PHP Evolving Recommendations (PERs)


    Раньше PHP-FIG выпускали только PSP-стандарты. Проблема в том, что некоторые подобные стандарты требуют постоянной доработки. Например, в случае с код-стайлом сейчас PSR-12 не включает новые возможности из PHP 7.4-8.0.

    Предлагается ввести новый тип рекомендаций PER, которые можно будет обновлять более оперативно.
  • 4 сентября — PHP fwdays'21 Online


    Совсем скоро пройдёт традиционная конференция от fwdays. Программа.

    Будет бесплатная трансляция всех докладов в день проведения (нужно зарегистрироваться).

    Есть дополнительные платные бонусы. Для них можно использовать промокод: HABRDIGEST.


PHP Internals


  • [RFC] Deprecate dynamic properties


    В текущих версиях PHP, если попытаться записать в несуществующее свойство, то оно будет автоматически создано.

    В современном коде это редко делается намеренно, чаще это опечатка или просто дурной тон.

    В этом RFC предлагается задепрекейтить и впоследствии удалить возможность создания динамических (необъявленных) свойств.
    ```php
    class User {
    public $name;
    }

    $user = new User;

    // Assigns declared property User::$name.
    $user->name = «foo»;

    // Oops, a typo:
    $user->nane = «foo»;
    // PHP <= 8.1: Молча создает динамическое свойство $user->nane.
    // PHP 8.2: Вызывает предупреждение, но все равно создает динамическое свойство.
    // PHP 9.0: Выбрасывает исключение Error.
    ```

    Это изменение не будет касаться класса `stdClass` и унаследованных от него. Поведение магических `__get`/`__set` также не затрагиваются этим изменением.
    ```php
    $obj = (object) []; // = new stdClass;

    // No deprecation warning
    $obj->foo = 1;

    class myStdClass extends stdClass {}
    $obj2 = new myStdClass;

    // No deprecation warning
    $obj2->bar = 1;
    ```

    Благодаря этому изменению в PHP 9.0 можно будет уменьшить размер объекта на 8 байт. На одном объекте это, конечно, ничто, но суммарно на больших приложениях будет заметно.

  • [RFC] User Defined Operator Overloads


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

    По сути, для каждого оператора предлагается определить свой магический метод, например `__add()` для ``+`` или `__equals()` для ``==``.

    С их помощью можно описывать желаемое поведение для объектов.```php
    $a = new Number(8);
    $b = new Number(6);
    $c = new Number(4);

    // Вместо такого
    $posRoot = $b->mul(-1)->add($b->pow(2)->sub($a->mul($c)->mul(4))->sqrt())->div($a->mul(2));

    // Можно будет сделать вот так
    $posRoot = ((-1 * $b) + ($b ** 2 — 4 * $a * $c)->sqrt()) / (2 * $a);
    ```
    В случае если предложение будет принято, то практически можно будет реализовать скалярные объекты.

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

  • cross[RFC] Nullable Intersection types


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


Инструменты


  • whsv26/functional — Автор столкнулся с проблемами существующих реализаций коллекций на PHP и написал свой пакет. Подробнее в статье Дженерик коллекции в PHP.
  • phpseclib/phpseclib — Реализация SSH, SFTP, RSA / DSA / ELLIPTIC CURVES, AES / CHACHA20 / ETC, X.509 на чистом PHP.
  • doekenorg/iterator-functions — Набор функций аналогичных встроенным `array_*`, но принимающих итераторы. На случай если не нравится классика от Никиты Попова nikic/iter.
  • azjezz/psl — Как могла бы выглядеть стандартная библиотека PHP.
  • php-censor/phpdoc-checker — Консольная утилита для валидации PHPDoc-блоков.
  • github-php/sponsors — Пакет для работы с API GitHub Sponsors. Можно организовать контроль доступа проверяя является ли пользователь спонсором.
  • paglliac/php-dependency-analysis — Инструмент для анализа зависимостей внутри проекта. Более продвинутые штуки можно делать с помощью qossmic/deptrac или phparkitect/arkitect.
  • ArtARTs36/GitHandler — Обертка над Git для PHP. Прислал Ukrainsky.
  • butschster/CronExpressionGenerator — Генератор cron выражений. Прислал butschster.
  • butschster/ray-server — Бесплатный сервер для отладки PHP приложений с помощью spatie/ray. Пост с обзором возможностей и деталями реализации. Прислал butschster.


Symfony




Laravel




Yii




Статьи




Аудио/Видео





Подписывайтесь на Telegram-канал PHP Digest.

Этот дайджест подготовлен совместно с Insolita. Если вам понравился выпуск, поставьте, пожалуйста, ему плюс.

Заметили ошибку или опечатку? Сообщите в личку хабра или телеграм.

Прислать ссылку можно через форму или просто написав мне в телеграм.
Поиск ссылок по всем дайджестам
Предыдущий выпуск: PHP-Дайджест № 209

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


  1. stalkerxxl
    30.08.2021 15:17
    -2

    >>>>разработчики обсуждают экосистему Carft CMS и потенциальный переход на Laravel

    ​еще один гвоздь.....


    1. Awilum
      31.08.2021 17:01

      Вполне адекватное решение.


      1. SamDark
        31.08.2021 20:24
        +1

        Там и плюсы и минусы. Технически одни минусы. В плане размера аудитории плюс.


    1. SamDark
      31.08.2021 20:24
      +3

      Подкаст стоит послушать прежде чем делать выводы.


  1. skiedr
    30.08.2021 16:22

    Я бы не стал рядом упоминать doekenorg/iterator-functions, реализующую итераторы, и библиотеку Никиты Попова nikic/iter, которая основана на генераторах.


    1. Maksclub
      30.08.2021 19:27
      +1

      почему это? критерий, который поставил их рядом — использование по аналогии с array_*


  1. bm13kk
    30.08.2021 16:29

    PHP Evolving Recommendations (PERs)

    сколько лет назад они выпустили новый стандарт? Зачем этим перекладыванием бумаги заниматься?


    1. pronskiy Автор
      30.08.2021 16:49
      +3

      Ты имеешь в виду, что можно было просто новый стандарт выпустить?


      1. bm13kk
        30.08.2021 17:01

        Весь смысл PHP-FIG - создавать стандарты. В силу кучи причин (решаемых и не очень) стандарты почти не создаются. Если мне не изменяет память - последний 3 года назад повился.

        С точки зрения результата - PHP-FIG мертв.

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

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


        1. pronskiy Автор
          31.08.2021 17:12
          +2

          Все-таки по поводу стандартов. Есть ощущение, что не так-то много их надо. Навскидку какие еще нужны?

          И от каких языков отстает в этом плане PHP?


          1. marvin255
            31.08.2021 17:49
            +1

            Я понимаю, что идея утопичная, но было бы здорово сделать стандарт для низкоуровневого доступа к БД (что-то вроде DAO из Yii или QueryBuilder из Laravel).

            Стандартизированные Consumer/Producer для очередей, ConsoleCommand (можно прям API symfony/console взять за стандарт), доступ к файловой системе (аналог flysystem), router.

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


            1. pronskiy Автор
              31.08.2021 19:16
              +2

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

              Разные фреймворки потому и появляются, что у людей разное видение на хороший API. Иначе можно было бы создать стандарт для фреймворка :-)

              Вот например symfony/console и так используется всеми. А те, кто его не используют — им, вероятно, не нравится как раз API.

              Сколько есть аналогов flysystem?

              Consumer/Producer — вот тут согласен. Есть вот такая инициатива https://github.com/queue-interop/queue-interop


              1. pbatanov
                01.09.2021 13:48
                +2

                Хотелось бы чтобы все основные части фрэймворков были бы полностью взаимозаменяемыми.

                Разные фреймворки потому и появляются, что у людей разное видение на хороший API

                Я тут на минуточку напомню, что FIG в PHP FIG - Framework Interop Group. И цель этой группы как раз делать интерфейсы, позволяющие делать совместимые компоненты, в частности, фреймворков. Чтобы можно было не писать, например, классы команд миграции доктрины отдельно для Yii, одельно для Symfony, Лары и тд, а написать один класс, который будет работать в любом из них, если ему через DI скормить правильные зависимости и правильно вызвать потом согласно спецификации стандарта.

                На условный DI же есть стандарт. Да, есть куча разных имплементаций и конфигурируются они все по-разному. Но стандарт есть и вполне успешный как по мне. Почему не сделать такой же для консоли?


          1. bm13kk
            01.09.2021 13:22

            У джавы и питона стандартов несколько сотен. И если в случае джавы - все усмехнуться "а как иначе?". То в случае питона это показатель.

            Я приведу пример одного стандарта. Но его особенность в том, что таких еще можно сотни сделать. Деньги.


            1. pronskiy Автор
              01.09.2021 15:12

              Список джавовских JSR, конечно, впечатляет https://jcp.org/en/jsr/all. Хоть и большинство из них не применимо к PHP.


        1. SamDark
          31.08.2021 20:29
          +2

          Два года назад. PSR-12.

          Но с тех пор появились занятные драфты:


          1. bm13kk
            01.09.2021 13:26

            Часы - интересный выбор. В системе есть еще имллион мест, где можно похожий интерфейс зделать. Например, getIP().

            доки уже лет 10 пиляти никак не закончат


  1. topuserman
    30.08.2021 16:42
    +1

    Если рассматривать [RFC] User Defined Operator Overloads
    то можно сразу и рассмотреть перегрузку методов и функций, чтобы не допускать таких извращений:
    public function __add(int|float|string|BigNumber $other, bool $left): self
    а в теле кучу if-else.


    1. Maksclub
      28.09.2021 17:49

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

      Если оператор — легкая относительно рантайма операция, по сути маппинг, то поиск подходящего метода с учетом иерархии типов (интерфесы, наследование) — дорого,

      плюс сложности при приведении типов, когда foo(int, string) и foo(string, int)