Свежая подборка со ссылками на новости и материалы. В выпуске: Laravel 5.6 и другие релизы, свежие RFC из PHP Internals, порция полезных инструментов, и многое другое.
Приятного чтения!



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



PHP Internals


  • [RFC] Fiber — Предлагается реализовать стэкфул-корутины, по сути, замыкания, которые можно ставить на паузу и возобновлять. При этом планирование (scheduling) выполняется на стороне пользователя, а не VM. Данное улучшение упростит написание асинхронных приложений и сделает, при этом выглядящими совсем как синхронные. Уже доступно расширение, и даже примеры использования.
  • [RFC] Deprecation of fallback to root scope — При использовании функций/классов внутри неймспейса, в случае если они не найдены, то будет попытка автоматически откатиться к глобальному скоупу. Предлагается упразднить данную возможность и бросать предупреждение:

    namespace Bar;
    strlen();
    // сначала попытка вызвать \Bar\strlen()
    // если не найдена, то будет вызвана \strlen()
    
    > Undefined function \Bar\strlen(), assumed \strlen()
    
  • [RFC] Deprecate backtick operator — Предлагается задеприкейтить оператор кавычки ``.


Инструменты




Материалы для обучения




Аудио и видео




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



Спасибо за внимание!

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

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

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


  1. Akdmeh
    12.02.2018 02:08

    «Deprecation of fallback to root scope» — зачем полностью ломать обратную совместимость скриптов? Это что, больше безопасности добавит? Придется ведь переписывать код всех существующих библиотек и скриптов!
    Редчайшая глупость, надеюсь, этот RFC не примут.


    1. SerafimArts
      12.02.2018 03:19

      Согласен, сообщество ещё не готово к подобным потрясениям, очень мало вижу код тех, кто указывает неймспейсы явно. Вон, в том же симфони это только недавно начали внедрять потихоньку. Так что этот RFC пока ещё не нужен.

      Но всё же тот факт, что указание явного неймспейса ускоряет код до 20% почти на пустом месте (за счёт снижения количество опкодов Zend VM) должно сильно подстегнуть разработчиков. Так что, думаю, года через 2-3 можно будет уже начинать думать об этом RFC.


      1. dizzy7
        12.02.2018 09:45

        Мало того что все все переменные идут с префиксом $, теперь ко всем функциям надо будет добавлять префикс \, банально неудобно. Функции в неймспейсах по опыту используются крайне редко, чтобы это делать мейнстримом, а проблему производительности возможно получилось бы решить на уровне оптимизаций opcache — в момент компиляции проверять существует ли функция в текущем/импортированном неймспейсах и если нет, сразу писать опкоды для вызова root-функции.


        1. Hello1
          12.02.2018 10:58

          Функции может не быть в момент компиляции, но она может появиться в runtime, привет eval.


          1. symbix
            12.02.2018 14:34

            Да какой eval? Достаточно обычного include. Файлы в Zend Engine компилируются независимо друг от друга, никаких заголовочных файлов, как в C, в PHP нет.


          1. SerafimArts
            12.02.2018 14:52

            В перепутали eval с поздним динамическим связыванием. В отличие от раннего, функции резолвятся из таблицы символов во время их непосредственного вызова, а не во время линковки.

            P.S. Для корректного резолва этих функций и генерируется нужный трёхадресный код (в нашем случае опкоды Zend VM), который указывает каким образом нужно обратиться к нашей функции. Указание неймспейса явно позволяет собрать эту команду в один единственный опкод с явным вызовом функции без резолва её неймспейса.


      1. Akdmeh
        12.02.2018 14:11

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


      1. gro
        12.02.2018 14:16

        Когда появились неймспейсы сам все функции начинал с \
        Сейчас смотрю, такой крндец…


        1. xotey83
          12.02.2018 18:09

          Теперь можно делать

          use function in_array;

          И далее в коде не использовать обратные слеши.


          1. wapmorgan
            12.02.2018 21:50

            А можно объединять импорт через ",":

            use function strlen, strpos, strrev;


            Еще как вариант: может стоит сделать «объединяющий» импорт (как, например, в питоне), чтобы не плодить десяток строк?
            use functions from zlib;
            // можно юзать все функции из http://php.net/manual/en/ref.zlib.php
            echo gzencode($_GET['abc']);


            1. Fesor
              12.02.2018 22:56

              А можно объединять импорт через ",":

              если это был вопрос — то да, можно:


              use function \{strlen, strpos, strrev};

              «объединяющий» импорт

              как разруливать конфликты имен? Нет уж, пусть лучше будет явным. Тем более что IDE за вас это все проставляют, да и это в целом неплохой способ быстро оценить связанность модулей. Смотрим на начало файла и понимаем от чего он зависит и что юзает.


              Увы PHP не JS что бы можно было писать в духе import * as foo from './foo'.


    1. m0rtis
      12.02.2018 18:50

      Deprecation — это же не удаление. Будут сыпаться нотисы. На мой взгляд, полезно. Сам уже давно настроил в PHPStorm автоподстановку слэша.


    1. Fesor
      12.02.2018 21:30

      Придется ведь переписывать код всех существующих библиотек и скриптов!

      В RFC включены ссылки на инструменты которые помогут вам это сделать. Так что не вижу проблемы. Более того, если в ветке 7x это не задепрекейтить, в 8-ку это уже никак не запихнуть.


      Это что, больше безопасности добавит?

      это добавит чуток производительности и сделает управление зависимостями более явным (что добавит в конечном итоге безопасности за счет статического анализа).


  1. JhaoDa
    12.02.2018 02:44

    daniilgrigorovabi/abimodelpattern — Операция «Ы» и новая библиотека ABI

    Зачем ЭТО в дайджесте?