PHP-Дайджест № 121 (20 ноября – 10 декабря 2017)


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


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



    PHP Internals


    • RFC: Explicit call-site pass-by-reference — Отличное предложение от Никиты Попова. На данный момент тот факт, что функция принимает аргумент по ссылке обозначается только в определении самой функции:

      function inc(&$num) { $num++; }
       
      $i = 0;
      inc($i);
      var_dump($i); // int(1)
      

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

      function inc(&$num) { $num++; }
       
      $i = 0;
      inc(&$i);
      var_dump($i); // int(1)
      

    Инструменты


    • yiisoft/di — Экспериментальный независимый от фреймворка и совместимый с PSR-11 DI-контейнер и инжектор от команды Yii.
    • PHPStan 0.9 — Отличный статический анализатор для PHP. Подробнее о релизе 0.9 в посте автора. Онлайн-песочница для проверки кода.
    • Indatus/trucker — Пакет для использования удаленных ресурсов API (обычно RESTful) как моделей в стиле ActiveResource.
    • coraxster/flysystem-owncloud, coraxster/flysystem-aws-s3-v3-minio — Пара провайдеров для Flysystem: Owncloud и Minio соответственно. Прислал corax.
    • acelot/automapper — Автомаппер данных для PHP 7. Прислал eee.
    • javibravo/simpleue — Простая очередь и воркеры с поддержкой AWS SQS, Redis, Beanstalkd в качестве бэкенда.
    • rectorphp/rector — Инструмент для обновления ваших приложений на основе AST.
    • apioo/fusio — Открытая платформа управления API на PHP.
    • TinyLara/TinyLara — Простой микрофреймворк.
    • arvenil/ninja-mutex — Реализация мьютекса для PHP с поддержкой различных адаптеров (flock, memcache, mysql, redis, ...).

    Материалы




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


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

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

    Прислать ссылку
    Поиск ссылок по всем дайджестам

    Предыдущий выпуск: PHP-Дайджест № 120

    Zfort Group 330,42
    Компания
    Поделиться публикацией
    Комментарии 25
    • +1
      ведь раньше так и писали
      function inc(&$num) { $num++; } 
      $i = 0;
      inc(&$i);
      var_dump($i); // int(1)
      
      • +1

        семантика отличалась. До php 5.4 вы таким образом передавали явно ссылку. Причем даже если функция собиралась по значению работать, так же можно было ссылку передать. Сейчас вы получите ошибку "call-time pass-by-reference". Предлагаю чуть поменять семантику — что бы указание на стороне вызывающего явной ссылки никак не влияло на рантайм и только на читабельность.

        • +1

          Да, формально семантика отличалась, но фактически вменяемые разработчики использовали именно так, как предлагается в нынешнем RFC. Когда вышел 5.4, я сильно недоумевал такому решению и, матерясь, вычищал амперсанды в вызовах по всему коду (благо, такого было немного).

          • 0
            Т. е. предлагают грубо говоря добавить еще один вид комментириев? Обоснование в RFC есть такое:
            As a simple example, consider the following two calls, which look deceptively similar:
            $ret = array_slice($array, 0, 3);
            $ret = array_splice($array, 0, 3);

            По мне это лучше, чем deceptively different
            $ret = array_splice($array, 0, 3);
            $ret = array_splice(&$array, 0, 3);
            • 0
              еще один вид комментириев?

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

              • 0
                Я в таких случаях представляю, как кто-то, кого я учу php, спросит у меня: а что делает амперсанд перед аргументом функции? А мне придётся сказать: ничего не делает.
                • 0

                  если функция принимает аргумент не по ссылке, то на такой код должно ругнуться.
                  доп. защита от описок.

                  • 0

                    Показывает, что переменная передаётся по ссылке. Явное лучше неявного и всё такое.

                    • 0
                      Я был бы за, если бы альтернативный синтаксис запретили. Хотя бы notice. Я видел, что в rfc говорится о том, что потом планируют и это предложить, вот в этом случае будет явное вместо неявного. Но сама по себе эта фича, на мой взгляд, просто внесёт путаницу.
                      • 0

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

                        • +1
                          Хм, вы правы. По моей логике получается, что наличие override в джаве плохо. Если ide будут подсвечивать пропущенный амперсанд, то полезная фича. Благословляю, можно принимать RFC :)
                          • 0
                            Будут, куда денутся ;)
          • 0

            Не могу понять зачем ввели тип object. Все равно когда нам нужно, гарантировать определенное поведение объекта мы делаем тайпхинт через интерфейс. А что по сути начит object — хоть что лишь бы не скаляр, массив, null и ресурс. Какое может быть у этого практическое применение?

            • 0

              могу предположить все что is_object($var) — а где пригодиться?
              пока думаю только прокси объекты — которым важно что через них был передан какой-либо объект, лишь бы только объект


              Что касается массива — думаю объекты описывающие интерфейсы массива все-таки пройдут

              • 0

                Навскидку:


                $request = json_decode($requestBody);
                process($request); // function process(object $request)
                • 0
                  Получается, еще один stdClass?
                  • 0

                    \stdClass — это исторически такая затычка для вопроса "что делать, если массив прикастили к object". Object же — это любой объект.


                    Согласен, что пример с json_decode не очень. Приведу пример получше — универсальные ORM, которые способны работать с Plain PHP Objects через Reflection, типа Doctrine 2.

                    • 0
                      Почему то я думал, что все объекты в PHP наследуют stdClass. Как же сильно я заблуждался. В таком случае Object — это то, что действительно давно пора было добавить в язык.
                    • 0

                      Скорее его абстрактный суперкласс :)

                  • +1
                    Какое может быть у этого практическое применение?

                    $container->get(SomeObject::class); // object
                    $entityManager->find($id); // object | null

                    по сути это нужно там, где вы делаете проверку на is_object и вас не интересует все остальное. Далее статический анализатор уже может убедиться в том что там на самом деле будет какой-то объект, а не строка. Это просто чуть сужает количество вариантов того что вы можете получить. Еще выгодно для чего-то что на рефлексии завязано например, где конкретный тип вам не интересен, а важно что это именно объект.

                    • 0

                      Вот, кстати, на подобных примерах хочется еще раз пустить слезу по поводу отсутствия в PHP Generics. :-)

                    • +1
                      Например, что-то вроде универсального гидратора?
                      • +1
                        Любой контейнер зависимостей. Сервис локатор. Гидратор. В ОРМ найдется применение
                        • 0

                          DI container?

                          • 0

                            Технически тип object заменяет в некоторых случаях сообщения типа Call to a member function <method>() on <non-object-type>) на Argument 1 passed to <method>() must be an object, <non-object-type> given. или выброс исключений при проверках типа if (!is_object($param)) throw new Exception('$param must be object'). Если таких ошибок у вас не встречается, то он вам особо и не нужен, да. Но на моей практике, это один из самых (если не самый) распростаненных типов рантайм ошибок в синтаксически правильном коде. Есть надежда, что синтаксические анализаторы теперь будут лучше ошибки такого плана выявлять.

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

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