Comments 27
Понимаю, что хотите охватить бОльшую аудиторию, размещая эти подборки в хабе «веб-разработка», но (дальше сугубо ИМХО) кому интересно – подпишутся на соответствующий хаб «PHP». У вас в подборках нет ничего, что требовало бы дополнительного хаба, всё исключительно про пых.
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;
}
Это и логичнее, если выбирать второй, тогда должно быть:

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


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

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

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


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

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

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


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

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

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

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

Для тех, кто прочитал это и подумал, будто в RingPHP cURL не используется: внутри RingPHP используется тот же самый cURL.
Насколько я понимаю, есть возможность реализовать любые хэндлеры и из коробки есть CurlHandler и StreamHandler, последний как раз не требует cURL. Поправьте если не прав.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Украина
Website
www.zfort.com.ua
Employees
101–200 employees
Registered