Pull to refresh

Comments 27

OMG, когда же это все читать/учить.
Спасибо.
Понимаю, что хотите охватить бОльшую аудиторию, размещая эти подборки в хабе «веб-разработка», но (дальше сугубо ИМХО) кому интересно – подпишутся на соответствующий хаб «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
Это должно быть невероятно быстрое решение для простых вещей, вроде логера или сборщика статистики/метрик.
RFC: Exceptions in the engine, RFC: Readonly Properties, RFC: UString — давно пора.
Удаление deprecated функций тоже как нельзя кстати. PHP меняется в лучшую сторону, что не может не радовать.
Ещё бы все стандартные функции привести к единообразному именованию, camelCase и запрятать в пространство имён и/или распределить по тематическим классам.
Есть же RFC от Попова с методами для скаляров в стиле js.
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. Поправьте если не прав.
Спасибо!

Однако по Zend маловато будет.
Sign up to leave a comment.