PHP Дайджест № 198 (25 января – 8 февраля 2021)

    Фото: Иван Ганцев.

    Обновление стандартов PSR-6 и PSR-13, кеширование наследования в опкеш, аксессоры свойств и другие новости из PHP Internals, диалект Lisp компилируемый в PHP, а также инструменты, видео, подкасты и PHP Дайджест Live.

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



    Новости и релизы



    PHP Internals


    • [RFC] Warning for implicit float to int conversions
      PHP динамический язык, что значит он может менять тип переменной на лету. У такого подхода есть как плюсы, так и минусы.

      Например, при преобразовании вещественных чисел (float) в целые (int) тихо теряется дробная часть.

      function acceptInt(int $i) {
          var_dump($i);
      }
      acceptInt(3.1415);
      
      > int(3)
      
      3v4l.org/C1bD3

      В данном RFC предлагается бросать предупреждение, если делается такое преобразование и дробная часть у float ненулевая.
    • Inheritance Cache
      Дмитрий Стогов представил PR, в котором реализовал кеширование наследования.

      Кеш на 8% улучшает производительность «Hello World» приложения на Symfony. И чтоб получить этот прирост, ничего делать не надо будет. Просто обновить PHP и удостовериться, что включен опкеш. Браво, Дмитрий!

      Скрытый текст
      Классы PHP компилируются и кешируются в opcache, но их «связывание» происходит во время выполнения при каждом запросе. Этот процесс может потребовать проведения ряда проверок на совместимость и заимствования методов/свойств/констант из родительских классов или трейтов. Все это требует много времени, хотя результат один и тот же в каждом запросе.

      Кэш наследования выполняет «связывание» набор всех зависимых классов (родительских, интерфейсов, трейтов, тип свойств, и т.п.) один раз и сохраняет в опкеше.

      Кроме того, в рамках этого патча Дмитрий удалил ограничения для неизменяемых классов. И теперь все классы, хранящиеся в опкеше иммутабельны.
    • [RFC] Property Accessors ! ранний черновик !
      Никита создал черновик предложения по аксессорам, то есть возможности объявлять геттеры/сеттеры для каждого свойства отдельно.

      Во-первых, RFC предполагает возможность объявлять асимметричные модификаторы доступа:

      class User {
          public string $name { get; private set; }
      
          // или вот так
          public string $prop { public get; private set; }
      }
      

      Также рид-онли свойства:

      class Test {
          // Read-write property.
          public $prop { get; set; } // равносильно `public $prop;`
      
          // Read-only property.
          public $prop { get; }
      }
      

      Во-вторых, добавлять валидацию с помощью ключевого слова guard.

      class User {
          public string $name {
              guard {
                  if (strlen($value) === 0) {
                      throw new ValueError("Name must be non-empty");
                  }
              }
          }
      }
      

      В-третьих, ленивую инициализацию с помощью ключевого слова lazy:

      class Test {
          public string $somethingExpensive {
              lazy {
                  return computeSomethingExpensive();
              }
          }
      }
      

      В 2013 году подобное предложение уже обсуждалось для PHP 5.5, но провалилось на голосовании.

      Пока это супер ранний черновик, который даже не обсуждался в Internals. На первый взгляд, предложение в текущем виде получается слишком сложным и, возможно, не стоит того. Но черновик просочился даже до публикации, так что посмотрим как он еще изменится.
    • [RFC] Fibers — Продолжается активное обсуждение файберов. Из интересного: к дискуссии подключился один из мейнтейнеров Swoole:
      Once PHP has a stack coroutine like Fiber, we can do more than what we can do now. Since we can interrupt from PHP internal functions, then we can replace all the implementation of PHP blocking functions, such as sleep(), and we can also replace php_stream so that we can change the implementation of PDO, mysqli, and phpredis into a coroutine way, and we can also make curl become a coroutine version through libcurl's support for multiplexing.
    • [RFC] Enumerations — Стартовало голосование по енамам. Подробнее о предложении можно прочитать в дайджесте №194 или посмотреть в видео дайджест-лайва.
    • [RFC] var_representation(): readable alternative to var_export() — Стартовало голосование по добавлению новой функции, которая исправляет проблемы старой var_export().
    • cross [RFC] Dump results of expressions in `php -a` — Отклонено.
    • Что нового в PHP 8.1 — Пополняющийся пост от Brent Roose. Если хочется прям все-все в подробностях, то лучше смотреть на php.watch.

      Следить за новыми RFC и ходом голосований также можно на PHP RFC Watch

    Инструменты


    • vimeo/php-mysql-engine — Симулятор MySQL-запросов (движок) на чистом PHP. В посте про инструмент Matt Brown, автор Psalm, рассказывает, как внедрение этого движка ускорило запуск тестов в Vimeo в два раза.

      На стриме возник вопрос: чем это лучше использования SQLite?

      Простой бенчмарк от Валентина Удальцова (канал Пых) показывает, что инструмент Vimeo заметно медленнее, чем PDO('sqlite::memory:'):
      sqlite:           4.00 MiB  - 66 ms
      php-mysql-engine: 10.00 MiB - 330 ms
      

      Поэтому, если для приложения достаточно подмножества SQLite, то можно остановиться на нем.
    • cweagans/composer-patches — Плагин для Cоmposer, который позволяет применять патчи к зависимостям. Удобно, если ваши изменения специфичные и не имеют смысла в виде полноценного PR для пакета/фреймворка, и на целый форк не тянут.
    • OndraM/ci-detector — Позволяет определить используемый CI-сервер и получить данные о билде.
    • rakibtg/SleekDB — NoSQL база данных на PHP. Данные хранятся в JSON-документах и есть язык запросов
    • Orangesoft-Development/throttler — Балансировщик нод. Пример использования для выбора прокси для Guzzle. Прислал Александр Денисюк.
    • sunrise-php/awesome-skeleton — Микрофрейморк на компонентах для разработки микросервисов и запуске на RoadRunner или Swoole. Прислал fenric.

    Symfony



    Laravel



    Yii



    Статьи



    Аудио/Видео



    Занимательное


    • Phel — Функциональный язык программирования, который компилируется в PHP. Является диалектом Lisp и вдохновлен Clojure. Пример кода:
      Скрытый текст
      # Define a namespace
      (ns my\example)
      
      # Define a variable with name "my-name" and value "world"
      (def my-name "world")
      
      # Define a function with name "print-name" and one argument "your-name"
      (defn print-name [your-name]
        (print "hello" your-name))
      
      # Call the function
      (print-name my-name)
      



    Уже пятый выпуск стрима по мотивам PHP Дайджеста будет сегодня на YouTube-канале PHP Point. Разбор новостей и ссылок из выпуска с подробностями и деталями. Новый ведущий, гость в выпуске, и по традиции конкурс со слониками.

    Начало в 20:00 Москва, Минск / 19:00 Киев.



    Если вы заметили ошибку или неточность — сообщите, пожалуйста, в личку хабра или телеграм.

    Больше новостей и комментариев в Telegram-канале PHP Digest.

    Прислать ссылку
    Поиск ссылок по всем дайджестам
    Предыдущий выпуск: PHP-Дайджест № 197

    Похожие публикации

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 6 277 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 17

      +2
      [RFC] Property Accessors

      Почему-то напоминает сильно Swift… Интересное предложение, с которым как и в Swift отпадает необходимость в геттерах и сеттерах, но визеры (withers) – не вымещает… Мне лично геттеры/сеттеры кажутся более правильным подходом, почему в Swift и продолжаю их использовать, хотя смысла в этом зачастую просто 0… Интересно было бы глянуть опрос за и против – gettes/setters vs property control среди пользователей...

        +1
        Почему бы для аксессоров не использовать аннотации?
          +2
          Полагаю потому, что аннотации так или иначе надо извлекать в рантайме для работы с ними (пусть сейчас это и удобней и является частью синтаксиса\стандартной библиотеки). А аксессоры должны работать, полагаю, на этапе преобразования в байткод (чтобы сформировать правильные методы и уровни доступа).

          Т.е. если упростить, то (в моем понимании) аннотации сами по себе ничего не делают. Что-то делает некоторый инструментарий (библиотека\фреймворк\самописный код), который на основе этих аннотаций как-то модифицирует свое поведение. И применение аннотаций для контроля выполнения кода в этом случае невозможно.
            0
            (в моем понимании)
            Все верно, это просто метаданные, доступные из Reflection API
              0
              Да, согласен stitcher.io/blog/attributes-in-php-8
              Keep in mind the goal of attributes: they are meant to add meta data to classes and methods, nothing more.
            +4
            А мне нравится черновик Никиты, надеюсь увидеть реализацию всего этого в 8.2.
              +2

              по-моему, сообщество в php давно созрело для создания нормальной стандартной библиотеки, а не вот этой мешанины в глобальном неймспейсе.
              так же очень полезны были бы нормальные структуры данных в ядре (https://github.com/php-ds/ext-ds).
              судьба fiber-ов, и прочей асинхронщины по прежнему туманна. ведь влом stream прослойку переписывать, проще и забавнее протолкнуть очередной дурацкий сахар в синтаксис, а не заниматься реально нужными вещами.

              +1
              Спасибо за подборку
                +3
                И еще несколько мероприятий с phpcommunity.ru


                  0
                  [RFC] Property Accessors
                  Да, есть некоторые базовые моменты, которые надо бы ввести, но реализация методов в свойствах, логику прописать… И ведь там примеры на 1-2 свойства, а если подумать: что произойдет, когда добавь ты с десяток свойств и еще методы??? И будет уже не класс PHP выглядеть, а как JSON в JS. А там до функционального ада недалеко.
                  Субъективно: идея интересная, но не продуманная и только изуродует существующее.
                    0
                    но реализация методов в свойствах,

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


                    И это особенно абсурдно звучит, т.к. "свойство" означает "поля класса с логикой". Т.е. критикуется предложение добавить свойства в язык, где их до сих пор просто не было.


                    P.S. Упс, промахнулся веткой.

                      0

                      А речь про php? Если внимательно прочитать, то фраза звучит следующим образом (в контексте php): "свойство — это свойство, но его не было". Когда не было? Где не было? А если не было в php, то когда появилось?

                        +1
                        А речь про php?

                        Речь про общепринятую во всём мире терминологию.


                        В PHP "поля" называются properties ("свойствами"), но не реализуют свойства, а являются обычными полями. Ваш капитан =)


                        Это было сделано для того, чтобы когда в нём (в PHP) появятся настоящие свойства — не переименовывать половину API рефлексии. Так же как как "анонимные функции" называются "замыканиями", но могут вообще не быть ими. И названо так для обеспечения совместимости, когда объект типа Closure ("замыкание") в некоторых случаях реализует настоящие замыкание (например, с помощью arrow function или use).


                        И RFC, предлагающий добавить наконец в PHP полноценную реализацию свойств, именно так, как они и должны примерно выглядеть ( https://ru.wikipedia.org/wiki/%D0%A1%D0%B2%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%BE_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5) ). На что комментарий, вида "зачем в PHP нужны свойства, ведь это всё переусложняет", напичканный совершенно неуместной и неподходящей терминологией, когда в тоже время — язык изначально проектировался и именовался, исходя из подобных будущих изменений.

                          0

                          После фразы, что речь идёт не про php, встало все на свои места. Ужасный и могучий php, не даёт тем же, к примеру, программистам на с# спать спокойно из за того, что php нарушает общепринятые нормы, этакий супостат!
                          Все ниже, что было по тексту, балалайка о трёх струнах. Короче, не убедили.

                            0

                            Осталось выяснить причём тут C#...

                              –2

                              Держите в курсе

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

                    Самое читаемое