PHP-Дайджест № 113 – свежие новости, материалы и инструменты (16 – 30 июля 2017)



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


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


    • PHP 7.2.0 Beta 1 — С первым бета-релизом заканчивается фаза активной разработки, а значит список новых возможностей в ветке 7.2 можно считать финальным. Следующая бета ожидается 3 августа. А пока можно попробовать PHP 7.2 из подготовленного Docker-образа.
    • PhpStorm 2017.2 — Улучшена интеграция с Composer и Docker, автозапуск тестов, и другое. Видеообзорvideo нововведений.
    • OpenAPI Specification 3.0.0 — Релиз спецификации для описания API, ранее известной как Swagger.
    • silexphp/Pimple 3.2.0 — DI-контейнер теперь с полной поддержкой PSR-11.
    • Bolt 3.3.0 — Популярная CMS на компонентах Symfony.

    PHP Internals


    • RFC: Same Site Cookie — В setcookie() и другие функции для работы с куки предлагается добавить поддержку стандарта Same-site Cookie.
    • RFC: Raise warnings for json_encode() and json_decode() issues — При возникновении ошибки во время вызовов json_encode()/json_decode() предлагается бросать ошибку класса E_WARNING, вместо использования функции json_last_error().
    • RFC: Short Closures — Предлагается короткий синтаксис для конвертации Callable в Closure:

      $writeln = {Util\writeln};
      // is a simplification for
      $writeln = Closure::fromCallable('Util\writeln');
      
      $writeln = {$terminal->writeln};
      // instead of
      $writeln = Closure::fromCallable([$terminal, 'writeln']);
      

    • RFC: Mixed typehint — Предлагается добавить mixed typehint:

      function foo(mixed $arg): mixed {
          return $arg;
      }
      

    Инструменты


    • jakzal/phpqa — Все популярные инструменты для статического анализа PHP в одном Docker-образе.
    • vaimo/composer-patches — Плагин для Cоmposer, который позволяет применять патчи к зависимостям. Прислал mougrim.
    • SecureHeaders v2.0 — Библиотека для работы с HTTP-заголовками связанными с безопасностью. Во второй версии упрощена интеграция с фреймворками. Подробнее об инструменте в посте.
    • igorw/evenement — Диспетчер событий вдохновленный EventEmitter из Node.js.
    • leproxy/leproxy — HTTP/SOCKS прокси-сервер на PHP.
    • jcupitt/php-vips — Биндинги для libvips, очень быстрой и легковесной библиотеки для работы с изображениями.
    • travello-gmbh/amazon-alexa-skill-skeleton — Скелет приложения на Zend\Expressive для разработки скиллов для Amazon Alexa.
    • nikic/php-ast — Расширение делающее абстрактное синтаксическое дерево доступным в userland.

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



    Аудио и видеоматериалы



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



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

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

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

    Метки:
    Zfort Group 385,57
    Компания
    Поделиться публикацией
    Комментарии 40
    • +2
      Спасибо!
      • 0
        > RFC: Mixed typehint — Предлагается добавить mixed typehint:

        Вот я не понимаю почему нельзя было добавить данный тип с самого начала, при внедрении типизации? Либо я один такой дурак и не мог грамотно реализовать паттерн repository без mixed?
        • +1

          А зачем в репозитории mixed? Репозиторий либо конкретную сущность возвращает, либо набор, т.е. array.

          • +8
            А в чем смысл mixed? Это же равносильно отсутствию какого либо тайпхинта
            • +4
              Ничего не указано — как вариант просто забыл указать или поленился.
              mixed — явно указано, что здесь mixed.
              • +3
                /sarcasm/
                предлагаем в следующей версии вместо пустой строки писать «this is empty line, nothing here»
                что бы точно быть уверенным в том, что здесь должна быть именно пустая строка, а не что-то важное, что ты просто забыл написать или поленился
                /sarcasm/
                • 0

                  Хорошая практика именно так писать в пустых try-catch.

                  • +1
                    Хорошая практика не писать пустых кетчей
                    • 0

                      По разному может быть, и зависит от контекста.

                    • 0
                      О, Сэм )

                      По поводу очередей на Yii2 — вроде, была инфа, что они пока не особо юзабельны, мол, пользуйтесь другими (сторонними) расширениям. Сейчас ситуация изменилась?
                    • 0
                      offtop

                      <irony>
                      Мир перевернулся в тот самый момент, когда SamDark решил поговорить о хороших практиках. Осталось услышать доклад от разрабов битрикса о каких-нибудь SOLID, SRP и прочих страшных штуках, и можно считать, что в жизни видел всё +))))
                      </irony>

                      • +2

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

              • 0

                Спорное улучшение. Как и nullable, поскольку ослабляет типизацию.

                • 0

                  Ослабляет типизацию, а также позволяет тут и там нарушать контракты, которые по идее должны быть заложены в интерфейсах...

                  • 0
                    mixed и так используется повсеместно и ослабляет типизацию.
                    теперь он только будет явно указываться.
                    • +1

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


                      И другое дело принять правило, но либо с оговоркой: не используем mixed, либо оставить лазейку лентяям.


                      Я за первый вариант без оговорок и двусмысленностей, как более строгий. И поэтому против mixed.

                      • +2
                        Категорично против mixed нельзя быть. Ну вот как например быть с реестром, про который я начал беседу? Вот запрашиваете вы registry->get($var) — и вот лично у меня фреймворк сейчас может вернуть bool, string или null. Как тут без mixed обойтись?
                        • 0
                          Ваше мнение по этому поводу, несомненно, имеет право на существование.
                          Но оно не имеет отношения к тому, что здесь обсуждается.
                    • +4
                      Ой господа, простите, не repository я имел ввиду а registry. С утра голова не заметила подвоха.
                    • +11
                      Лучше бы реализовали как в phpdoc сейчас пишут — варианты типов данных: string[]|string, например.
                      Это позволило бы сильно снизить вообще необходимость такого типа как mixed.
                      • 0
                        Попахивает. Зачем в одном методе возвращать массив или строку?
                      • 0
                        Если вводить типизированные массивы, придётся каждый раз в рантайме обходить весь массив и проверять каждый элемент.
                        • +2

                          А сейчас это и так приходится делать вручную через foreach или какой-нибудь Webmozart\Assert.

                          • 0
                            Но зачем?
                            • +1

                              Как зачем? Чтобы не прилетало что попало. Целостность данных, все дела.

                              • 0
                                Это вы вообще везде этим занимаетесь?
                                • 0

                                  Только если массив должен быть наполнен объектами пользовательского типа данных.

                                • 0
                                  Используйте ArrayAccess etc. И шлите туда-сюда объекты. Прилетел объект, условно StringSlice, все ок. И не надо никуда по циклам бегать. Если, конечно, я все правильно понял.
                                  • 0

                                    Как ArrayAccess спасет от доступа к несуществующему индексу и от того, что нужно знать, какие индексы существуют?

                                    • 0
                                      Спасет от перебора. Легко. Но я его посоветовал использовать не поэтому. А для того, чтобы в []string ничего, кроме string не попадало.
                        • 0

                          Лучше бы static typehint добавили.

                          • +4

                            static — это рантайм, а вся типизация резолвится статически, как в константах и аргументах методов (там, например, нет static, но есть self и в т.ч. доступны примитивные операции). Именно по-этому тайпхинтинг не появится никогда =)

                          • +3
                            При возникновении ошибки во время вызовов json_encode()/json_decode() предлагается бросать ошибку класса E_WARNING


                            Шёл 2017-й год, а они всё бросали ворнинги.
                            • +1
                              В обсуждении вроде очень критично отнеслись к RFC. Да и я почти точно уверен, что не пройдет.
                              • 0

                                в 2017 warning-и являются исключениями

                                • 0
                                  Для поддержания совместимости со старьём, а не для того, чтобы новые добавлять.
                                • 0
                                  Уже предложили ввести флаг, при включении которого будет эксепшен
                                  • 0

                                    В 7 можно его впоймать через try catch, видимо потому такое предложение

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

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