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

Поделиться с друзьями
-->

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


  1. gogolinsky
    31.07.2017 09:20
    +2

    Спасибо!


  1. daggert
    31.07.2017 09:21

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

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


    1. franzose
      31.07.2017 09:33
      +1

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


    1. oxidmod
      31.07.2017 09:34
      +8

      А в чем смысл mixed? Это же равносильно отсутствию какого либо тайпхинта


      1. gro
        31.07.2017 11:57
        +4

        Ничего не указано — как вариант просто забыл указать или поленился.
        mixed — явно указано, что здесь mixed.


        1. edogs
          31.07.2017 13:17
          +3

          /sarcasm/
          предлагаем в следующей версии вместо пустой строки писать «this is empty line, nothing here»
          что бы точно быть уверенным в том, что здесь должна быть именно пустая строка, а не что-то важное, что ты просто забыл написать или поленился
          /sarcasm/


          1. SamDark
            01.08.2017 01:20

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


            1. oxidmod
              01.08.2017 09:14
              +1

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


              1. Zhuravljov
                01.08.2017 22:52

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


            1. mariczzz
              02.08.2017 10:56

              О, Сэм )

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


              1. SamDark
                02.08.2017 15:30

                Да.


            1. SerafimArts
              02.08.2017 17:10

              offtop

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


              1. SamDark
                02.08.2017 18:08
                +2

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


    1. samizdam
      31.07.2017 10:52

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


      1. franzose
        31.07.2017 11:24

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


      1. gro
        31.07.2017 12:03

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


        1. samizdam
          31.07.2017 14:47
          +1

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


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


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


          1. daggert
            31.07.2017 14:59
            +2

            Категорично против mixed нельзя быть. Ну вот как например быть с реестром, про который я начал беседу? Вот запрашиваете вы registry->get($var) — и вот лично у меня фреймворк сейчас может вернуть bool, string или null. Как тут без mixed обойтись?


          1. gro
            31.07.2017 17:37

            Ваше мнение по этому поводу, несомненно, имеет право на существование.
            Но оно не имеет отношения к тому, что здесь обсуждается.


    1. daggert
      31.07.2017 11:05
      +4

      Ой господа, простите, не repository я имел ввиду а registry. С утра голова не заметила подвоха.


  1. Gemorroj
    31.07.2017 10:08
    +11

    Лучше бы реализовали как в phpdoc сейчас пишут — варианты типов данных: string[]|string, например.
    Это позволило бы сильно снизить вообще необходимость такого типа как mixed.


    1. Fr05t1k
      31.07.2017 10:16

      Попахивает. Зачем в одном методе возвращать массив или строку?



    1. gro
      31.07.2017 12:08

      Если вводить типизированные массивы, придётся каждый раз в рантайме обходить весь массив и проверять каждый элемент.


      1. franzose
        31.07.2017 12:13
        +2

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


        1. gro
          31.07.2017 12:53

          Но зачем?


          1. franzose
            31.07.2017 12:59
            +1

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


            1. gro
              31.07.2017 13:27

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


              1. franzose
                31.07.2017 13:46

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


            1. Alexeyco
              07.08.2017 17:23

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


              1. franzose
                07.08.2017 23:35

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


                1. Alexeyco
                  08.08.2017 10:39

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


  1. Fr05t1k
    31.07.2017 10:19

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


    1. SerafimArts
      31.07.2017 10:55
      +4

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


  1. gro
    31.07.2017 12:13
    +3

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


    Шёл 2017-й год, а они всё бросали ворнинги.


    1. Layan
      31.07.2017 14:21
      +1

      В обсуждении вроде очень критично отнеслись к RFC. Да и я почти точно уверен, что не пройдет.


    1. FanatPHP
      31.07.2017 17:47

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


      1. gro
        31.07.2017 17:53

        Для поддержания совместимости со старьём, а не для того, чтобы новые добавлять.


    1. Aptop
      31.07.2017 23:56

      Уже предложили ввести флаг, при включении которого будет эксепшен


    1. ifalur
      31.07.2017 23:56

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