PHP-Дайджест № 158 (3 – 17 июня 2019)


    Свежая подборка со ссылками на новости и материалы. В выпуске: PHP 7.4.0 alpha 1, DevConfX, принятые и новые RFC из PHP Internals, порция полезных инструментов, и многое другое.

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



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



    PHP Internals


    • [RFC] Allow throwing exceptions from __toString() — Предложение принято единогласно.
    • [RFC] Numeric Literal Separator — Предложение преодолело порог на голосовании, и значит в PHP 7.4 можно будет использовать символ подчёркивания в качестве разделителя в числах:

      $i = 197_823_459; // 197823459
    • [RFC] Nullsafe Calls — Старое предложение снова обсуждается в Internals. В нём рассматривается возможность добавления нового оператора ?->, который бы позволил делать безопасные цепочки вызовов методов, в случае когда возвращаемое значение может быть null:

      $o?->mayFail1()?->mayFail2()?->mayFail3()?->mayFail4();

      Подобное предложение есть и в ECMAScript, а в Hack данная возможность уже реализована.
    • [RFC] Alternative «use» syntax for Closures — Автор предложения считает синтаксис use в замыканиях не очень удобным и предлагает перенести его в тело функции:

      Скрытый текст
      // Так сейчас
      $closure = function (
          ArgumentType $argument1,
          ArgumentType $argument2,
          ArgumentType $argument3,
          ArgumentType $argument4
      ) use ($importVariable1, &$importVariable2, $importVariable3, &$importVariable4): ReturnType {
          // ...
      };
      
      // Предлагается вот так
      $closure = function (
          ArgumentType $argument1,
          ArgumentType $argument2,
          ArgumentType $argument3,
          ArgumentType $argument4
      ): ReturnType {
          use $importVariable1, &$importVariable2;
          use $importVariable3, &$importVariable4;
      
          // ...
      };
      
    • audio PHP Internals News #13 — Sara Goleman (релиз менеджер PHP 7.2) и Derick Rethans (PHP 7.4) общаются на тему менеджмента релизов.
    • audio PHP Internals News #14 — С Никитой Поповым об исключениях в __toString().

    Инструменты


    • badoo/liveprof — Инструмент мониторинга производительности приложений. На Хабре о нём был пост и можно посмотреть демо.
    • BrainMaestro/composer-git-hooks — Управление Git-хуками из сomposer.json.
    • hirak/prestissimo — Плагин Composer для параллельного скачивания пакетов. Значительно ускоряет установку зависимостей.
    • ronanguilloux/IsoCodes — Библиотека для валидации различных стандартных кодов: почтовые индексы (zip) всех стран, телефонные номера, кредитные карты, национальные идентификационные коды и другие.
    • zetrider/BotAuth — Аутентификация при помощи ботов в соцсетях. habr Пост в поддержку.

    Symfony



    Laravel



    Yii



    Security



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



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

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

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

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

    Поделиться публикацией

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

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

      +1

      Спасибо!


      Дженерики в PHP — Что это такое и для чего они нужны

      Статья про дженерики несколько не полна без вот этой милой ссылочки (осторожно, не вздумайте пользоваться!)

        0
        Еще вот такая штука есть github.com/preprocess/pre-generics
          0

          Ох. Readme пустой, на сайте coming soon, зато code of conduct есть! :-)

            0
            :-) думаю скелет пакета из шаблона генерировался, так что не удивительно, а родительский проект preprocess.io давно известен.
        +3
        Nullsafe Calls — как по мне, очень полезная штука. Надеюсь, её примут.
          0

          Согласен. Я был в восторге, когда эта фича появилась в C#, и мне очень не хватает её в PHP.


          Правда в PHP один из методов в цепочке может помимо null вернуть какой-нибудь тип отличный от ожидаемого, но это уже другой разговор, фича всё равно крутая.

            0
            один из методов в цепочке может помимо null вернуть какой-нибудь тип отличный от ожидаемого
            В PHP7 не может, появились return type declarations.
              0

              Это если его декларировать function myMethod(): ?SomeType;, если его опустить function myMethod(); то метод по прежнему может возвращать что угодно.

                +1

                Да, но писать код, объявляя типы всё ещё не обязательно. И даже если для себя принято такое правило, сторонний код не обязан ему подчиняться.

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

                  Инверсия управления — наше всё )
                0
                А расскажите нам непросвященным.

                В чем киллер-фича (кроме билдеров) вызова тройной и более цепочки?
                  +1
                  Вот ожидаете вы получить объект с вложенным объектом и обратиться к какому нибудь свойству последнего. Но так сложилось, что в обоих случаях вместо объекта может быть и нул. И вот, предлагается сахарок, чтобы упростить конструкции с проверками на нул.
                    –1
                    А теперь расскажите мне.

                    <?php $obj?->getOne()?->getTwo();


                    На каком из этапов я получил null?
                      +2
                      Это не важно в задачах где предлагается использовать такую конструкцию.
                        +2
                        Вам в общем случае не должно требоваться обращение к третьему уровню вложенности стейта.
                        Если это произошло, то у вас что-то пошло не так как минимум в рамках SRP
                          +2
                          Представьте, что вся эта цепочка чейнинга — вложенные DTO.
                          Где в таком случае нарушается SRP и закон Деметры?
                            0
                            Вам в общем случае не должно требоваться обращение к третьему уровню вложенности стейта.
                            Если это произошло, то у вас что-то пошло не так как минимум в рамках SRP

                            Хм, извините, но причем тут я…

                            Ну если уж на то пошло, то я бы и не стал на этом архитектуру делать. Вытащить что-то из ответа апи, мапнуть данные в другую структуру, форматирование во вьюхе — вон там это может пригодиться. При работе с тупыми объектами данных.
                      +1
                      Любая конвеерная обработка в таком виде, в большинстве случаев, выглядит нагляднее.
                  +1
                  > [RFC] Allow throwing exceptions from __toString() — Предложение принято единогласно.
                  Это не первый ли случай в истории? )
                  –1
                  Автор предложения считает синтаксис use в замыканиях не очень удобным и предлагает перенести его в тело функции

                  1. Не вижу ничего неудобного.
                  2. Поменьше бы подобных изменений, автору предложения похоже просто нечем заняться.
                    0
                    Господа, у меня вопрос не в тему, но давно волнующий. Какова вероятность, что состоится вот это изменение wiki.php.net/rfc/php8/merge_member_symbol_tables?

                    Сильно ломанёт совместимость. В моём хозяйстве точно, в каких-то библиотеках тоже видел. Всегда считал это фичей PHP. То что можно сделать метод, который работает с одноименным свойством. Стоит ли начинать отучаться от этого подхода?
                      0
                      Насколько я вижу, RFC в статусе черновика и явно не закончен, так что вероятность есть, но думаю не скоро.
                        +1
                        This strategy is based on the assumption that modifying the smallest amount of the engine is probably the best way forward. If we discover there are other benefits (perhaps in significantly reduced memory) we may unify the symbol tables.

                        Здесь не совсем верный посыл.
                        1 — Это не упростит модификацию движка, а усложнит, поскольку придется постоянно проверять, что именно извлечено из HashTable
                        2 — Каких либо заметных преимуществ по памяти это не даст, поскольку объем значащих данных не поменяется, а HashTable он и в Африке HashTable — ключ->указатель. Кроме того, возможно сами значащие данные придется как-то тэгировать для упрощения работы с ними

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

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