Pull to refresh

Comments 16

Новости не могут не радовать.
Новый psr для времени хорош.
Спорный rfc про очистку глобального нэймспэйса, как в итоге получится три экрана use в начале класса, либо колхоз со сбором всего добра в хэлперы. Это если и функции разбить на расширения, очень пострадает процедурная парадигма. А в глобально что оставить? Core? То есть var_dump etc. В целом конечно не плохо, но нужен будет какой то переходной момент с режимом legacy. Я про то что в перспективе implode и explode разбегутся)
P.S. Сейчас есть такая штука как use functions

что случилось с выходом PHP 7.3.28? гугление не даёт никакой информации.
ну так Security Support Until 6 Dec 2021, отсюда и вопрос.
как-то слабо верится, в то что за месяц ни одного бага не было найдено и исправлено.
PhpStorm 2021.1 EAP

Моя любимая версия за последние несколько лет. Очень шустро работает когда в коде много алиасов (а это как раз случай при разработке Yii 3).

Среди голосовавших против трое мейнтенеров Swoole. Они считают, что в Swoole уже пройден весь путь по асинхронному PHP, а файберы — это попытка начать заново, и их добавление не несет пользы без других компонентов.

Файберы дадут стандартизацию. Можно будет писать ассинхронный код и использовать различные библиотеки для его запуска, не привязываясь например к Swoole.
Стартовало голосование по файберам.

Хорошим тоном, особенно для таких масштабных и спорных RFC, было бы дать в нём ссылку на дискуссию или хотя бы процитировать основные мнения "против" в нём самом. Сейчас, поневоле, возникает ощущение, что голосующими хотят манипулировать, вынося на голосование только аргументы "за".


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


Также против голосовал

Расмус тоже против, кстати.

Расмус на конференциях положительно высказывался про файберы. Возможно, он имел в виду предложение от Дмитрия https://wiki.php.net/rfc/fiber А сейчас я не видел его сообщений в internals. Были такие?


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

Расширение имеет же историю за плечами, ему года 3 минимум.

Расширение имеет же историю за плечами, ему года 3 минимум.

Оу! Да, это я дал маху конечно. Но вот, если честно, это ещё больше сомнений добавило. 146 звёзд за 3 года существования расширения, всего 8 Issues, только два из которых про баги… Это говорит либо о том, что написано очень качественно, либо о том, что при всей хайповости, не особо то кому и нужно… Так много вопросов и так мало ответов :D


А сейчас я не видел его сообщений в internals.

А там вообще как-то очень скудно с обсуждением этого RFC. Как и в чате на стеке кстати. У меня такое впечатление, что многие сами пока не определились. С одной стороны движение в сторону, куда давно хотят, а с другой сомнение, точно ли в ту сторону движение (меня именно это удерживает от участия).


PS Ну и в любом случае ситуацию уже не переломить. Можно считать, что предложение принято.

Спасибо, дядьки!

Это выглядит как сладкий сон
str_contains() -> String\contains()
in_array() -> Array\contains()

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

Было бы замечательно, если бы опционально, без использования классов (свойства класса), можно было переменные делать со статическим типом данных.
вы про такое? Это было возможно уже очень давно, ещё со времён пхп 4, как минимум.

function abc(){
    static $variable = 0;
    $variable++;
    echo $variable;
}
abc(); // prints 1
abc(); // prints 2
abc(); // prints 3
abc(); // prints 4

Sign up to leave a comment.

Articles