Дайджест интересных новостей и материалов из мира PHP № 50 (6 октября – 26 октября 2014)



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

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


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




    PHP


    • RFC: Exceptions in the engine — Предложение реализовать вместо фатальных ошибок обычные исключения было отклонено ранее как слишком кардинальное для минорной версии PHP. Теперь же предлагается включить данную возможность в релиз PHP 7. В отличие от предыдущего варианта, в этом кроме фатальных ошибок также станет возможным отлавливать ошибки парсинга.
    • RFC: Objects as hash keys — Предлагается добавить магический метод __hash(), что позволит использовать объекты в качестве ключей массивов.
    • RFC: Return Type Declarations — Обновленное предложение по type hinting для возвращаемых значений. Предлагаемый синтаксис: function getUser(): User { return new User(); }
    • RFC: Readonly Properties — Предлагается добавить еще один модификатор доступа readonly, который будет обозначать свойства доступные для записи внутри класса и только для чтения вне его.
    • RFC: UString — Предложение включить расширение ustring в ядро, таким образом, получить класс UString инкапсулирующий работу с юникод-строками.
    • RFC: Safe Casting Functions — Предлагается добавить функции to_int(), to_float() и to_string(), которые будут возвращать false в случае, если передаваемое значение не может быть приведено к соответствующему типу.
    • RFC: Remove deprecated functionality in PHP 7 — Предложение удалить все deprecated возможности в PHP 7.
    • RFC: Anonymous Classes v2 — Вторая попытка реализовать анонимные классы в PHP.
    • RFC: PHP 7.0 timeline — План релизов PHP 7. Финальная версия предполагается в октябре 2015 года.
    • PHP 5.6 constants — Интересная недокументированная возможность PHP 5.6: массивы можно присваивать константам.


    Инструменты


    • ApistКак использовать API сайта, у которого нет API? Ответ прост — использовать библиотеку SleepingOwl Apist.
    • Greppy — Библиотека для продвинутой работы с регулярными выражениями в PHP.
    • Pixeler — Отрисовка изображений в консоли юникод-символами.
    • Naegleria — Компилятор Brainfuck реализованный на PHP.
    • StatsDClientBundle — Мониторинг Symfony 2 приложения.
    • — Нанобиблиотека для работы с событиями. Код умещается в 103 символа.
    • Distill — Умный распаковщик архивов для PHP. Пост об использовании.
    • Dunit — Позволяет протестировать код на различных версиях PHP с помощью Docker.


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




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




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




    Быстрый поиск по всем дайджестам
    ← Предыдущий выпуск
    Zfort Group
    112,00
    Компания
    Поделиться публикацией

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

      +4
      OMG, когда же это все читать/учить.
      Спасибо.
        –4
        Понимаю, что хотите охватить бОльшую аудиторию, размещая эти подборки в хабе «веб-разработка», но (дальше сугубо ИМХО) кому интересно – подпишутся на соответствующий хаб «PHP». У вас в подборках нет ничего, что требовало бы дополнительного хаба, всё исключительно про пых.
          0
          RFC: Return Type Declarations — Обновленное предложение по type hinting для возвращаемых значений. Предлагаемый синтаксис: function getUser(): User { return new User(); }


          Вот такой подход к описанию возвращаемых значений меня несколько раздражал в ActionScript. На мой взгляд более логичным было бы задействовать описание типов в стиле Java или C. Мне кажется более удобным первый вариант (могут быть методы и с большим количеством параметров):

          integer public function someParametricMethod($param1, array $param2, array $param 3) {
              // ...
              return $integerValue;
          }
          


          public function someParametricMethod($param1, array $param2, array $param 3) : integer {
              // ...
              return $integerValue;
          }
          
            +1
            Это и логичнее, если выбирать второй, тогда должно быть:

            public function someParametricMethod($param1, $param2: array, $param: array) : integer {
                // ...
                return $integerValue;
            }
            


            Но почему-то все склоняются именно к нему.
              0
              а как тогда указывать значение по умолчанию?
                0
                public function someParametricMethod($param1, $param2: array, $param: array = []) : integer {
                    // ...
                    return $integerValue;
                }
                
                  0
                  на мое мнение, в java сделано лучше всего:

                  public function int someParametricMethod($param1, array $param2, array $param = []) {
                      // ...
                      return $integerValue;
                  }
                  
                    0
                    Вопрос был не где лучше, а в смешивании двух стилей как в Java и как в ActionScript.
              +1
              со стандартными типами да — так более красиво, но из стандартных типов мб только array, а если там будет указан длиннющий класс да еще с неймспейсом? название метода будет уже нелегко найти-прочитать
                +4
                public static static function foo() { return new static; }
                

                и
                public static function foo(): static { return new static; }
                


                вот…
                  0
                  С другой стороны, если ради удобства парсинга вводится типизация в другом стиле (к вопросу единообразия) то получается двоякая ситуация: вроде уже и так понамешано, особенно в именах функций PHP, так что стиль задания типизации роли не сыграет, а если задуматься — уж если делать, то следовать какой-то общей парадигме развития языка. Если конечно имеется таковая.
                    +3
                    Это для удобства чтения а не для удобства парсинга. Вот вы по первой натации сможете понять что там происходит? Вас не смутит static static? А теперь прочтите новую натацию: Публичный статический метод foo который возвращает static. Примерно такой же синтаксис например в go.
                    0
                    Возвращаемый функцией тип в первом случае логичнее писать всегда после ключевого слова function.
                  +1
                  Этот дайджест сегодня оказался очень познавательным, в частности из-за:
                  Простое API на Nginx и PostgreSQL — Идея интересна тем, что API реализовано только на Nginx и PostgreSQL без использования каких-либо языков программирования.
                  Не думал, что так можно делать!)
                  Покапавшись побольше, нарыл то, что мне захочется проверить в ближайшее время: github.com/simpl/ngx_mongo
                  Это должно быть невероятно быстрое решение для простых вещей, вроде логера или сборщика статистики/метрик.
                    +3
                    RFC: Exceptions in the engine, RFC: Readonly Properties, RFC: UString — давно пора.
                      +1
                      Удаление deprecated функций тоже как нельзя кстати. PHP меняется в лучшую сторону, что не может не радовать.
                        0
                        Ещё бы все стандартные функции привести к единообразному именованию, camelCase и запрятать в пространство имён и/или распределить по тематическим классам.
                          0
                          Есть же RFC от Попова с методами для скаляров в стиле js.
                            0
                            Я как-то баловался с подобным в качестве модуля.
                              0
                              Str\padL('bar', 20);
                              

                              Вы считаете что это симпатичнее чем
                              str_pad('bar', 20, 'foo', STR_PAD_LEFT);
                              

                              Тогда уж можно было бы делать как-то так:
                              std\str\padLeft('bar', 20, 'foo');
                              


                              Что до падения производительности, вы делали замеры с opcache? Было бы любопытно к слову. А так, если в 7-ом пыхе добавят JIT, есть шанс что все будет инлайниться и падение производительности будет незначительным.

                              Но в целом я не считаю что это добавит красоту языку. Мне кажется что текущие RFC которые фиксят странности в поведении таких вещей как инкремент/декремент намного важнее.
                                0
                                Я вообще делал «use UnifiedPHP\Str as S» и потом «S\padL()». Компактный 2х символьный префикс получался.
                                С именами да, padLeft возможно и понятнее => лучше.

                                По скорости там, где просто другое название метода — нет падения (просто алиасы), где перестановка параметров и прочие небольшие изменения — есть, но ощутимо меньше, чем при вызове через call_user_func*. Инлайн/JIT моему исполнению не поможет — у меня ж сишный модуль.

                                Основная проблема в неоднородности как названий так и порядка следования параметров. Это и исправлял)
                                  0
                                  JIT/opcache должны помочь если это будет php-шный модуль. То есть оптимизации на уровне опкодов/байткода.
                                    0
                                    Для php кода да, конечно. Но UnifiedPHP-то у меня простая so'шка.
                                    Если будет достойный JIT, то появится, я надеюсь, масса всяких классных штук, которые раньше были проблематичны из-за скорости выполнения.
                        +1
                        В качестве транспортного слоя отныне выступает RingPHP, а cURL является опциональным.

                        Для тех, кто прочитал это и подумал, будто в RingPHP cURL не используется: внутри RingPHP используется тот же самый cURL.
                          +1
                          Насколько я понимаю, есть возможность реализовать любые хэндлеры и из коробки есть CurlHandler и StreamHandler, последний как раз не требует cURL. Поправьте если не прав.
                          +1
                          Спасибо вам!
                            0
                            Спасибо!

                            Однако по Zend маловато будет.

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

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