PHP-Дайджест № 85 – интересные новости, материалы и инструменты (24 апреля – 15 мая 2016)



    Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.

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


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


    • PHP 5.5.35, 5.6.21, 7.0.6 — Обновления актуальных веток с исправлениями проблем безопасности.
    • Проблема безопасности в IDE от JetBrains — Уязвимость содержится во всех IDE на платформе IntelliJ версии v2016.1 и старее, включая PhpStorm. Апдейты выпущены, обновляемся.
    • habr Множество уязвимостей в ImageMagick, одна из которых ведёт к RCE
    • PSR-14 Event Manager — Черновик нового стандарта от группы PHP-FIG.
    • State of the FIG — Несколько представителей PHP-FIG выразили желание покинуть группу, так как практически не принимают участие в обсуждении новых стандартов: Laravel, Propel, Doctrine, Guzzle. Также в ответ на чрезмерную бюрократизацию появилась инициатива PHP Community Driven Standards, в рамках которой предлагается дать возможность участвовать в создании стандартов всем желающим. Будем надеяться на дальнейшую эффективную работу PHP-FIG и интересные предложения от сообщества.
    • DevConf-2016 — 17 июня в Москве пройдет очередная ежегодная конференция для веб-разработчиков. PHP-секция представлена интересными заявками: «Развитие ветки PHP-7.*» от Дмитрия Стогова, «Безопасность: от базовых принципов до особенностей PHP» от Александра Макарова, «Как Badoo перешли на PHP7 и сэкономили $1M» от Юрия Насретдинова и другие.
    • habr Yii 2.0.8 — Под капотом сотня исправлений и улучшений.
    • Bolt 3.0.0 — Релиз популярной CMS на компонентах Symfony.
    • Go! AOP Framework 2.0.0


    PHP


    • RFC: Pipe Operator — Предлагается портировать оператор |> из Hack, что позволит записывать цепочки вложенных вызовов в более читаемом виде:
      $ret = scandir($arg)
          |> array_filter($$, function($x) { return $x !== '.' && $x != '..'; })
          |> array_map(function ($x) use ($arg) { return $arg . '/' . $x; }, $$)
          |> getFileArg($$)
          |> array_merge($ret, $$);
      

    • RFC: Semi-Automatic CSRF Protection — Предлагается реализовать полуавтоматическую защиту от CSRF из коробки с помощью сессий.
      Форму
      <form action="http://example.com/edit.php" method="POST">
      <textarea name="comment"></textarea>
      <input type="submit" />
      

      можно автоматически будет обезопасить с помощью вызова
      session_start(['csrf_rewrite'=>SESSION_CSRF_POST, 'csrf_validate'=SESSION_CSRF_POST]);
      

    • RFC: Intersection Types — Предлагается сделать возможным указание группы типов для аргументов. При этом передаваемое значение должно реализовывать все типы:
      function RecordsToList(Countable & Traversable $input): String { }
      

      В случае если также будет принято предложение RFC: Union Types, станет возможным гибкое указание типов:
      function RecordsToList(Array | (Countable & Traversable) $input): String { }
      

    • RFC: Simple Annotations — Упрощенные аннотации в противовес атрибутам, предложенным ранее. В данном случае аннотации это массив PHP-выражений.
    • RFC: Nullable Types — Принято предложение, которое позволяет передавать null в качестве аргумента с указанным типом:
      function foo_nullable(?Bar $bar) {}
       
      foo_nullable(new Bar); // valid
      foo_nullable(null);    // valid
      foo_nullable();        // invalid
      

    • RFC: Catching Multiple Exception Types — Предложение принято. В PHP 7.1 станет возможным отлов нескольких типов исключений в одном catch-блоке:
      try {   
          // Some code...
      } catch (ExceptionType1 | ExceptionType2 $e) {
         // Code to handle the exception
      } catch (\Exception $e) {
         // ...
      }
      

    • PHP 7.1 — В июне ожидается уже первая альфа PHP 7.1. Также для грядущей версии выбраны релиз-менеджеры: Davey Shafik и Joe Watkins.
    • @PHPRFCBot — Твиттер-аккаунт для тех, кто хочет следить за новыми RFC для PHP. Также напомню про специальный ресурс php-rfc-watch.beberlei.de для мониторинга RFC.


    Инструменты


    • undemanding/difference — Библиотека позволяет оценить различия между изображениями.
    • sensiolabs-de/deptrac — Инструмент статического анализа кода для определения зависимостей между слоями приложения. Видеотуториал и пост в поддержку.
    • ronanguilloux/IsoCodes — Библиотека для валидации различных стандартных кодов: Zip-коды 175 стран, телефонные номера, номера кредитных карт, ISBN, национальные идентификационные коды и другие.
    • rocketeers/rocketeer — Инструмент для запуска задач и развертывания приложений. Туториал по использованию.
    • paragonie/halite — Криптографическая библиотека для PHP. Обертка над libsodium. Пост об использовании в поддержку.
    • K-Phoen/Rusty — Инструмент позволяет реализовать тесты в аннотациях а-ля Rust.
    • webdevops/clitools — Набор консольных инструментов для ускорения работы с Docker, PHP, MySQL.
    • usmanhalalit/pixie — Годный query builder.
    • cboden/Binky — Консольный мини-клиент для AMQP.
    • tightenco/collect — Коллекции из Laravel отдельным пакетом.
    • ihor/Nspl — Набор полезных функций для программирования в функциональном стиле.
    • slevomat/coding-standard — Расширенный стандарт кодирования для PHP_CodeSniffer.
    • bartblaze/PHP-backdoors — Подборка бэкдоров на PHP.


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




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

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

    Присылайте ссылки на интересные статьи или полезные инструменты, которых не было в PHP-Дайджестах, и ваше имя будет рядом с присланной ссылкой в выпуске.

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

    Zfort Group
    113,00
    Компания
    Поделиться публикацией

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

      +3
      И RFC атрибуты и simple annotation просто ужасны, синтаксис и то как преподнесена идея аннотаций.
        0
        dim_s ничего не поделаешь, нужен синтаксис совместимый с php, а не совершенно отдельный язык в языке, как в случае с доктриной. Собственно в самих RFC об этом сказано, а синтаксис выбран из уже существующих языков (Hack). p.s. прошу прощения за ответ в основном треде, а не на коммент — мобильный клиент, он такое не умеет.
          +3
          >> и << являются операторами сдвига, ничего совместимого с синтаксисом не вижу. В питоне декораторы начинаются с @, в Java аннотации с @, в Dart аннотации тоже с @, а то что они предлагают, причем там еще и expression это полный бред. Аннотации это декларативность, а не императивность!
            0
            абсолютно согласен. тащат из других языков, но каверкают на свой лад. например namespace separator. зачем "\"?
              0

              Потому что во времена php 5.x лексер не умел такие штуки разруливать. В php7 в качестве разделителя нэймспейсов можно юзать уже точки к примеру, но уже обратная совместимость...

                –2
                а аннотации? в 5 их не было, но это не мешает сделать их в стремном виде. этот пайп оператор опять же — а чем просто | плохо? у них же теперь контектно-зависимый парсер, он в курсе, что палка это пайп, а не ИЛИ.
                  +1

                  А что делать в тех случаях, когда нужна "функия_а или функция_б"? Из какого контекста лексер будет исходить? Мысли разработчика он читать не умеет. ;)

                    0
                    например namespace separator. зачем "\"?

                    Тогда я вас не понял вообще.

                    +2

                    Точки нельзя, и даже не из-за лексера. Т.к. конфликтует с конкатенацией дефайнов, тоже самое и с прямым слешем — деление дефайнов. Раньше (в php 6) думали над двойным двоеточием, но под конец убрали, из-за проблем с вложенными классами (напоминаю, в php7 можно чейнить статик методы через A::b()::c(), но резолв класса из константы пока не работает, в будущем, предполагаю, поправят, так что получится A::b::c, где b и с — константы класса).


                    Если уж ругаться на что-то, то на оператор конкатенации, вместо плюса, который решает тучу проблем с приведением типов (вспомним JS и его дикий угар с оператором "+"). Отсюда и переиначивание, берут то что есть в других языках, но делают так, чтобы это не было проблемой в будущем, как, например с дженериками в джаве (https://www.youtube.com/watch?v=HE4yyPpUsy4).


                    Предполагаю, что отсюда и именование аннотаций, пусть и не очень красиво (хотя я бы сказал просто непривычно), но зато консистентно и не будет проблем как, например сейчас с ассоциативными массивами, синтаксис которых был взят под копирку из перла. Хотя, предполагаю, что "двойные скобки" добавят проблем с операторами сдвига в подходах с контрактным программированием.


                    Короче, я к чему, такой "необычный" синтаксис не потому, что авторы упоролись, а потому что они сидели и долго думали, проектируя язык так, чтобы в будущем не возникало проблем в развитии и введении необходимых фич.

                      +1
                      после такого аргумента, им уже можно все простить ;)
              +3
              Pipe Operator однозначное зло. Уж лучше бы вмержили расширение scalar_objects Никиты Попова, которое решает ту же самую проблему сильно элегантнее.
                +1
                Вообще то он решает другую проблему, хотя и суперский экстенщен
                  0

                  Цитата из статьи:


                  позволит записывать цепочки вложенных вызовы в более читаемом виде

                  Экстеншн scalar_objects решает именно эту проблему.
                  Сорри, это пример плохой в статье приведён с array_fitler и array_map. В самом RFC гораздо более продуктивный пример, который действительно через scalar_objects не решить

                    +1
                    Вот нет, scalar_objects решает другую:

                    This extension implements the ability to register a class that handles the method calls to a certain primitive type (string, array, ...). As such it allows implementing APIs like $str->length().

                  +1
                  Pipe Operator однозначное зло.

                  когда кто-то завяляет об "однозначности" зла — стоит задуматься в том сколько человек обдумывал эту идею или это чистой воды субъективизм.


                  Уж лучше бы вмержили расширение scalar_objects Никиты Попова, которое решает ту же самую проблему сильно элегантнее.

                  Вот только давайте подумаем… pipe-оператор не требует изменения кода, решение от Никиты — требует как минимум обертки. Не знаю как вы, а мне pipe-оператор дико нравится, хоть с функциональными выражениями было бы намного лучше:


                  $ret = scandir($arg)
                      |> array_filter($$, $x => $x !== '.' && $x != '..' })
                      |> array_map($x => $arg . '/' . $x, $$)
                      |> getFileArg($$)
                      |> array_merge($ret, $$);

                  Ну и выбор $$ в качестве плэйсхолдера сомнителен, _ как в JS выглядит уже приятнее и логичнее.


                  Опять же посмотрим внимательно на пример выше. Предположим что с filter/map никаких проблем, они уже есть в хэндлерах для массивов. Далее допустим мы array_merge можем заменить на concat тот же. А что делать с getFileArg? Выходит пока так:


                  
                  return $ret->concat(
                     getFileArg(
                        scandir($arg)
                           ->filter(function($x) { return $x !== '.' && $x != '..'; })
                           ->map(function ($x) use ($arg) { return $arg . '/' . $x; })
                  ));
                  

                  Как-то это не сильно решает проблему. И добавлять getFileArg как хэндлер ЛЮБЫХ массивов явно мы не можем. Делать объектную обертку? Зачем, чистая функция, зачем ее в объект заворачивать...


                  Словом я двумя руками за, это позволит сильно упростить код некоторых методов моих объектов.

                    0

                    Блин, ну я же там написал уже, что вот эти вот array_map и array_filter через пайп оператор ну прямо скажем что неудобно.
                    Что касается остального — полностью согласен.
                    Одним словом я не против пайп-оператора, я против того чтобы его наличие стало аргументов против вмерживания scalar_objects.

                      0
                      через пайп оператор ну прямо скажем что неудобно.

                      Более чем удобно, мне только плэйсхолдер не нравится и отсутствие лямбд. А так — удобно) просто попробуйте)


                      Вообще надо бы реализовать это дело на yay.


                      я против того чтобы его наличие стало аргументов против вмерживания scalar_objects.

                      я не против scalar_objects, я против того что бы убирали возможность работать просто с функциями и против того что бы пользователи могли из userland "манкипатчить" скаляры добавляя свои обработчики.

                  +5

                  Прокомментирую, пожалуй, про PHP-FIG. Разлада как такового нет. Покинули группу те, кто достигли своих целей или кто не может найти времени на обсуждения.


                  CDS пока занятен, но очень хаотичный. Посмотрим, что из него получится.

                    +1
                    Пасиба за комментарий, обновил текст.

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

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