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

[DevMan]

OMG, когда же это все читать/учить.
Спасибо.

[rinat_crone]

Понимаю, что хотите охватить бОльшую аудиторию, размещая эти подборки в хабе «веб-разработка», но (дальше сугубо ИМХО) кому интересно – подпишутся на соответствующий хаб «PHP». У вас в подборках нет ничего, что требовало бы дополнительного хаба, всё исключительно про пых.

[janson]

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;
}

[dim_s]

Это и логичнее, если выбирать второй, тогда должно быть:

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

Но почему-то все склоняются именно к нему.

[B_Dmitry]

а как тогда указывать значение по умолчанию?

[dim_s]

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

[mariner]

на мое мнение, в java сделано лучше всего:

public function int someParametricMethod($param1, array $param2, array $param = []) {
    // ...
    return $integerValue;
}

[dim_s]

Вопрос был не где лучше, а в смешивании двух стилей как в Java и как в ActionScript.

[annenkov]

со стандартными типами да — так более красиво, но из стандартных типов мб только array, а если там будет указан длиннющий класс да еще с неймспейсом? название метода будет уже нелегко найти-прочитать

[Fesor]

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

и

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

вот…

[janson]

С другой стороны, если ради удобства парсинга вводится типизация в другом стиле (к вопросу единообразия) то получается двоякая ситуация: вроде уже и так понамешано, особенно в именах функций PHP, так что стиль задания типизации роли не сыграет, а если задуматься — уж если делать, то следовать какой-то общей парадигме развития языка. Если конечно имеется таковая.

[Fesor]

Это для удобства чтения а не для удобства парсинга. Вот вы по первой натации сможете понять что там происходит? Вас не смутит static static? А теперь прочтите новую натацию: Публичный статический метод foo который возвращает static. Примерно такой же синтаксис например в go.

[dim_s]

Возвращаемый функцией тип в первом случае логичнее писать всегда после ключевого слова function.

[zBit]

Этот дайджест сегодня оказался очень познавательным, в частности из-за:

Простое API на Nginx и PostgreSQL — Идея интересна тем, что API реализовано только на Nginx и PostgreSQL без использования каких-либо языков программирования.

Не думал, что так можно делать!)
Покапавшись побольше, нарыл то, что мне захочется проверить в ближайшее время: github.com/simpl/ngx_mongo
Это должно быть невероятно быстрое решение для простых вещей, вроде логера или сборщика статистики/метрик.

[MTonly]

RFC: Exceptions in the engine, RFC: Readonly Properties, RFC: UString — давно пора.

[maximkou]

Удаление deprecated функций тоже как нельзя кстати. PHP меняется в лучшую сторону, что не может не радовать.

[MTonly]

Ещё бы все стандартные функции привести к единообразному именованию, camelCase и запрятать в пространство имён и/или распределить по тематическим классам.

[marapper]

Есть же RFC от Попова с методами для скаляров в стиле js.

[AterCattus]

Я как-то баловался с подобным в качестве модуля.

[Fesor]

Str\padL('bar', 20);

Вы считаете что это симпатичнее чем

str_pad('bar', 20, 'foo', STR_PAD_LEFT);

Тогда уж можно было бы делать как-то так:

std\str\padLeft('bar', 20, 'foo');

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

Но в целом я не считаю что это добавит красоту языку. Мне кажется что текущие RFC которые фиксят странности в поведении таких вещей как инкремент/декремент намного важнее.

[AterCattus]

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

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

Основная проблема в неоднородности как названий так и порядка следования параметров. Это и исправлял)

[Fesor]

JIT/opcache должны помочь если это будет php-шный модуль. То есть оптимизации на уровне опкодов/байткода.

[AterCattus]

Для php кода да, конечно. Но UnifiedPHP-то у меня простая so'шка.
Если будет достойный JIT, то появится, я надеюсь, масса всяких классных штук, которые раньше были проблематичны из-за скорости выполнения.

[catanfa]

В качестве транспортного слоя отныне выступает RingPHP, а cURL является опциональным.

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

[pronskiy]

Насколько я понимаю, есть возможность реализовать любые хэндлеры и из коробки есть CurlHandler и StreamHandler, последний как раз не требует cURL. Поправьте если не прав.

[cawakharkov]

Спасибо вам!

[seyfer]

Спасибо!

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