PHP-Дайджест № 125 (29 января – 11 февраля 2018)


    Свежая подборка со ссылками на новости и материалы. В выпуске: 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

    Zfort Group 273,15
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 17
    • +3
      «Deprecation of fallback to root scope» — зачем полностью ломать обратную совместимость скриптов? Это что, больше безопасности добавит? Придется ведь переписывать код всех существующих библиотек и скриптов!
      Редчайшая глупость, надеюсь, этот RFC не примут.
      • +1
        Согласен, сообщество ещё не готово к подобным потрясениям, очень мало вижу код тех, кто указывает неймспейсы явно. Вон, в том же симфони это только недавно начали внедрять потихоньку. Так что этот RFC пока ещё не нужен.

        Но всё же тот факт, что указание явного неймспейса ускоряет код до 20% почти на пустом месте (за счёт снижения количество опкодов Zend VM) должно сильно подстегнуть разработчиков. Так что, думаю, года через 2-3 можно будет уже начинать думать об этом RFC.
        • +3
          Мало того что все все переменные идут с префиксом $, теперь ко всем функциям надо будет добавлять префикс \, банально неудобно. Функции в неймспейсах по опыту используются крайне редко, чтобы это делать мейнстримом, а проблему производительности возможно получилось бы решить на уровне оптимизаций opcache — в момент компиляции проверять существует ли функция в текущем/импортированном неймспейсах и если нет, сразу писать опкоды для вызова root-функции.
          • +2
            Функции может не быть в момент компиляции, но она может появиться в runtime, привет eval.
            • 0

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

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

                P.S. Для корректного резолва этих функций и генерируется нужный трёхадресный код (в нашем случае опкоды Zend VM), который указывает каким образом нужно обратиться к нашей функции. Указание неймспейса явно позволяет собрать эту команду в один единственный опкод с явным вызовом функции без резолва её неймспейса.
            • 0
              Если это дает явное ускорение — тогда это должно быть на усмотрение разработчиков, нужно им это ускорение или нет.
              • 0
                Когда появились неймспейсы сам все функции начинал с \
                Сейчас смотрю, такой крндец…
                • 0
                  Теперь можно делать
                  use function in_array;

                  И далее в коде не использовать обратные слеши.
                  • 0
                    А можно объединять импорт через ",":
                    use function strlen, strpos, strrev;


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

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


                      use function \{strlen, strpos, strrev};

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

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


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

              • 0

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

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

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


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

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

                  • –2
                    Уж лучше тогда соглашение принять — функцию, вызванную без "\", считать глобальной, а для текущего неймспейса придумать еще один спецсимвол. Не хватало там еще одного спец-символа конечно, но как часто вызывается какая-то функция в текущем неймспейсе. Никогда практически. А корневого повсюду. Ввести что-нибудь типа ".\" для вызова из текущего. Да, ужас. Но ведь ставить слэш перед всеми вызовами глобальных функций или прописывать use это же вообще кошмар и просто рутина повседневная будет.
                    • +1
                      просто рутина повседневная будет.

                      IDE или же какие-нибудь авто тулы будут заниматься этой рутиной за вас.

                      • 0
                        Уже разобрался. Вчера сильно испугался от этой новости) Никогда не даже задумывался что это фалбэк. Для красоты в языке конечно же должно быть так как есть.
                  • +3
                    daniilgrigorovabi/abimodelpattern — Операция «Ы» и новая библиотека ABI

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

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

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