PHP-Дайджест № 62 – интересные новости, материалы и инструменты (26 апреля – 11 мая 2015)



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

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


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




    PHP


    • RFC: Short Closures — В PHP 7.1 предлагается реализовать короткий синтаксис для анонимных функций: $x ~> $x + 1; Подобное уже реализовано, например, в Hack: $x ==> $x + 1;.


    Инструменты


    • voryx/ThruwayWAMP (Web Application Messaging Protocol) роутер и клиент для PHP.
    • Sami — Генератор документации к API. Туториал.
    • MacFJA/PharBuilder — Автоматизирует создание phar из Composer-пакета.
    • Visithor — Библиотека для тестирования роутов на ожидаемые HTTP-коды. Пост в поддержку.
    • phpbadge — Инструмент для создания svg-бейджей.
    • davispeixoto/PHP-Batch — Библиотека для реализации батч-процессинга.
    • wapmorgan/PhpCodeAnalyzer — Анализатор используемых расширений PHP в коде, не включенных в ядро. Прислал wapmorgan.
    • PHPPm — Менеджер пакетов, один из возможных вариантов развития composer. Прислал wapmorgan.
    • AsyncTask — AsyncTask делает возможным правильное и простое использование потока. Прислал dmamontov.
    • DavBackup — Создание резервных копий сайтов в облаках через WebDAV. Прислал dmamontov.
    • gatakka/PGF-Router — Концепт роутера без использования регулярных выражений.
    • Codebug — PHP Xdebug client frontend — Легковесный отладчик для Mac OS X.
    • dantleech/phpbench — Инструмент для бенчмарков.
    • libphonenumber for PHP — Библиотека для парсинга, форматирования и валидации международных телефонных номеров.
    • BitOne/php-meminfo — Расширение предоставляет информацию об использовании памяти в PHP.
    • JakubOnderka/PHP-Parallel-Lint — Инструмент проверки синтаксиса, анализирующий файлы параллельно.
    • TidalLabs/Slacker — Консольный клиент для Slack.


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




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


    • Cherimola Library — Когда обычных true и false недостаточно. Прислал elfet.


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

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

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

    Zfort Group
    111,74
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      –3
      RFC: Short Closures — В PHP 7.1 предлагается реализовать короткий синтаксис для анонимных функций

      Вот не могу понять зачем это нужно? Глазами ведь выцепить такое при чтении кода будет в разы сложнее.
        +2
        Нужно — сейчас слишком многословно получается, но вот тильда?! *рука лицо*
          –1
          Ну сейчас по-крайней мере анонимная функция при её описании выглядит как функция. А вот это '~>' — сахар ради сахара?
          Раздел с описанием предлагаемого синтаксиса — настораживает. Получится такая же шаурма со стилем именования функций PHP, за что его ругают, но только теперь — с новым синтаксисом.
          Теперь — банановый.
            +1
            > А вот это '~>' — сахар ради сахара?

            А вот это есть практически во всех языках (и даже в java где оно совсем-совсем чужеродно), ибо набирать километры незначащего кода очень быстро надоедает.
          +2
          У меня возникает только один вопрос, почему нельзя использовать комбинацию "->" вместо "~>".
            +1
            Убогий парсер. Из-за этого практически все новые синтаксические конструкции вводятся с помощью новых ранее не используемых символов (пространства имен, например), а т.к. "->" уже занято, то выбрали свободную тильду (минусующий, как её набирать то?).
              +1
              Так они же тотально переписывали парсер и теперь всё должно было стать круто.
                0
                Они точно переделали внутренности интерпретатора (http://habrahabr.ru/post/222219/) за счет чего и получили ускорение, а вот насчет парсера я не уверен.
                0
                Мне интересно, чем оно забито, если такой комбинации еще нет. Даже если считать что это "-" и ">", то как тогда реализовали "=>" как "=" и ">" и плюс к этому в foreach и объявлении массивов?
                  +2
                  $obj->method();
                    +1
                    Совсем забыл, точно. Облом =( Тогда понятно почему ~>, а ==> выглядит еще более убого.
              0
              У вас очень правильное замечание. Мне кажется следует использовать правило как в других языках — больших анонимок лучше использовать полное function, а для однострочных ~>
              В примерах есть usort($array, ($a, $b) ~> $a->val <=> $b->val);
              usort($array, function($a, $b) { $a->val <=> $b->val; }); — PSR этот код просит разнести на пару строк из-за {}
              +1
              PSR-7 уже на повторном голосовании. Проходит с перевесом.
                0
                А оно кому-то вообще нужно? Особенно учитывая что они сами пишут что практически все существующие библиотеки не используют value object…
                  +1
                  Всем нужно, это первый шаг к тому чтобы в итоге библиотеки были заточены не под фреймворки а под php в целом.
                    0
                    Кроме того, это позволяет авторам фреймворков подумать вместе над серьёзными архитектурными штуками. Одна голова — хорошо, десять лучше.
                    0
                    На самом деле да:

                    1. Изолируют request/response практически все современные фреймворки, но делают это каждый по своему.
                    2. value object не нужен до тех пор пока мы не начнём использовать что-то вроде reactphp.org или daemon.io. Они всё более популярны. Знаю человека, который запускал по такому принципу Yii в продакшне.
                      0
                      2. А там вроде уже не настоящий value object — в последней версии разрешено возвращать $this из with* если оно не привело к изменению значения, интересно, какие из with* методов подходят?
                        0
                        Разве возврат того же инстанса в случае не изменения значения противоречит value object?
                          0
                          Как/кем определяется изменилось значение или нет?
                            0
                            Классом, реализующим интерфейс. Скорее всего, все будут делать так:

                            if ($this->something === $newValue) {
                                return $this;
                            }
                            
                              0
                              Вот, только это значит что в разных реализациях вполне может оказаться что изменение внутренностей не будет создавать клон. Утрируя: ну вот решил автор что при изменении заголовков сам запроса не меняется, а сама библиотека при этом офигенно-офигенная и нужна в нашем древнем проекте просто позарез — привет цепочки, привет отладчик, прощайте выходные… Если уж решили создать свой 15 стандарт с блекджеком и ..., то надо было делать максимально однозначно.
                                0
                                Не не не, если реализация по PSR, то при изменении (если данные поменялись) обязан создаваться новый инстанс. Этот момент как раз оговаривается явно.
                        0
                        Я вот ещё смотрю на RingPHP, который под капотом Guzzle 5+ — тоже вроде какая-то абстракция над HTTP. Как это всё соотносится?
                          0
                          PSR сделан теми же людьми, см. member projects. На него со временем большинство там упомянутых перейдут.

                          Вообще PSR-ы пишутся бег оглядки на существующие реализации. На будущее.
                    +2
                    github.com/davispeixoto/PHP-Batch — классы все пустые.
                      0
                      Там в описании внизу написано: An amazing «Thank you, guys!» for Jetbrains folks, who kindly empower this project with a free open-source license for PhpStorm — кто-то запилил себе бесплатную лицензию на PhpStorm, понаписав open-source пустых классов!)
                      0
                      Замкание всей области видимости в функцию — это, мне кажется, слишком не «php way». Появятся проблемы с производительностью и циклическими ссылками, которые ещё не готовы решать.
                        +3
                        10 вещей про симфони признано экстремистским материалом.
                        Фабпот подсуетился.
                          +2
                          Замкание всей области видимости в функцию — это, мне кажется, слишком не «php way». Появятся проблемы с производительностью и циклическими ссылками, которые ещё не готовы решать.

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

                          вот новое ядро — это хорошо.

                          если уж захотелось сделать покороче… то простой почти безболесненный способо это сделать ввести алиас для function — например fun

                          но этж ну вообще не главное!

                          надо думать о развитии SPL!!!
                            0
                            С чего вы взяли, что такая фишка есть только в скале, ерленге и хаскеле. Короткий синтаксис есть в C#, Java 8, C++, Dart, JavaScript (ES6), Perl6, Groovy, Python, Swift и еще во многих языках. Он полезен и удобен, особенно во всяких event-подобных штуках.

                            Замыкание скорее всего будет производится не всей области видимости, а только тех переменных, которые используются внутри функции, главное чтобы разработчики php верно реализовали это.
                              0
                              Да, действительно. ...all variables used in the body of the anonymous function will automatically be bound to the anonymous function closure from the defining scope.

                              Вещь в любом случае интересная.
                              +1
                              надо думать о развитии SPL!!!

                              И в первую очередь — о его производительности. SPL-итераторы — очень интересная вещь, но тормоза в 7 раз по сравнению с обычными циклами — это жуть.
                                0
                                Итераторы обычно нужны для экономии памяти, для ленивых операций над коллекциями. В задачах где требуются итераторы тормоза в 7 раз не делают погоды. Цепочка итераторов способна творить чудеса по производительности, как пример Stream API из Java 8.
                                  0
                                  Ну вот у меня есть задачи, где использование итераторов значительно сократило бы и объем кода и его читаемость, но я вынужден был отказаться от них именно из-за тормознутости.

                                  … как пример Stream API из Java 8

                                  Так в том-то и дело, что речь о реализации SPL-итераторов в PHP
                                    0
                                    В любом случае, итераторы нельзя сделать быстрее, они никогда не смогут работать быстрее обычного цикла или с такой же скорость. Это объекты, вызовы методов, поднимается стек вызовов и на все это затрачивается время. Я думаю итераторы можно немного оптимизировать по скорости выполнения, но не намного.
                              +3
                              PHPPm и хостингер не выдержали хабраэффекта
                                0
                                Поменял ссылку на гитхаб github.com/PHPPm/phppm
                                  +1
                                  А в кратце можно в чем их фишка? По гитхабу то считай тот же композер)
                                    +1
                                    Это менеджер composer-пакетов, которые собираются вести себя как системные пакеты, то есть имеют бинарники, конфиги в /etc, логи в /var/log и т.д.
                                0
                                Лучше вместо короткого синтаксиса анонимных функций сделали бы что-то похожее на stream API в java 8 www.deadcoderising.com/java-8-no-more-loops, только нативное, кстати вот реализация в одном фреймворке ouzo.readthedocs.org/en/latest/utils/functions.html#extract
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    +3
                                    Быть. Уверен. Новые штуки выходят с использованием всего и я бы не стал утверждать, что новых штук на PHP не выходит, это всё-таки 82% всего веба.
                                      0
                                      82% от количества проектов, а не от количества посещаемости этих проектов. Миллион проектов на вордпресе и других cms делают эту статистику, но это же не значит, что в этих проектах участвует программист. Если бы можно было бы посчитать процент проектов, в которых участвовал программист, то это была бы справедливая статистика.
                                        +2
                                        М… хабр, Yahoo, Facebook, Wikipedia, Flickr, Digg, SourceForge, Вконтакте, mailchimp, Etsy, Zynga. Мало? Могу ещё.
                                          0
                                          PHP is used by 82.0% of all the websites whose server-side programming language we know.


                                          Пишут, что от количества сайтов. Facebook -> Google, Microsoft, Bing, SourceForge -> Github, Bitbucket, Вконтакте -> Одноклассники, Twitter, можно приводить бесконечное число известных крупных проектов сделанных не на php. Поэтому я написал, что берут они от количества, т.е. любая минимальная страничка сделанная на php +1 к этому рейтингу.
                                            +1
                                            Конечно они считают количество. Посещаемость мало кто отдаёт. И всё-таки, я считаю, что такая метрика популярности довольно справедлива. Ничто не мешает делать мелкие проекты на том же Python или Ruby или Perl… на чём угодно. Но почему-то они не популярны для этих целей. В то же время, сверхкрупные проекты на PHP делаются и успешно.

                                            Я не утверждаю, что PHP очень хорош как язык, но он развивается, он отлично подходит для веба, лучше, чем остальные, и будущее у него определённо есть. Даже если он умрёт, то медленно и не скоро.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                +1
                                                Websockets чатик на пхп делается не сложнее чем на любом другом языке socketo.me/demo
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    +2
                                                    На странице все более чем общепринятые практики.
                                                    Написано, что будет работать на чистом PHP, но если хотите улучшить производительность, то можете установить дополнительные расширения.
                                                    Но даже на стандартном наборе этот сервер будет держать десятки тысяч соединений без проблем.

                                                  +1
                                                  Что позволяет вам делать подобные заявления?


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

                                                  Потому что именно на нём сделали Wordpress и у него были конкуренты под .NET и Java точно, но вот не взлетели из за гемора с развёртыванием и хостингом. То же про Drupal, Joomla и т.д.

                                                  Вебсокеты — не подавляющее большинство проектов. Я бы даже сказал, что довольно редко нужны. Ну и не вижу особых проблем с ними работать из PHP. Конечно, сразу всплывают требования к окружению, но они сходные и в случае Python или Ruby.
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                      0
                                                      Мы сейчас про PHP или про Symfony? Symfony — довольно сложная штука и требования соответствуют. Wordpress, Drupal, Joomla и т.д. заводятся практически везде. Даже на устаревших версиях десятилетней давности.
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                        0
                                                        Обминусовывать не буду :) Вы аргументируете и не перегибаете. Хороший спор :)
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                  +1
                                                  Знаю на тему Yahoo. Они бы так и использовали PHP для фронта. Также знаю проекты, где сайт (то есть CMS, всякие формы фидбека и т.д.) делается на PHP, а продукт на Java. Причём изначально делалось всё на Java и впоследствии сайт был переписан на PHP. Причины — не надо билдить, правки вносить быстрее, это может делать менее дорогой сотрудник, найти и заменить которого значительно легче.
                                                    +1
                                                    Ещё могу сказать про наш stay.com. Также делали бы на PHP, хотя отдельные части у нас бегают на go, а приложения, естественно, на Java и ObjectiveC.

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

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