Меня больше всего настораживает, что они хотят включить его сразу в ядро, что может привести к большой боли в будущем, когда окажется, что что-то не учли или сделали неправильно.
Расширение имеет же историю за плечами, ему года 3 минимум.
Цитата странная, согласен, но в предложении говориться как раз об обратном. Там речь о том, чтобы убрать strict_type, но запретить многие неявные преобразования по дефолту. Например вот такие:
false -> int # No more conversion from bool
true -> string # No more conversion from bool
7.5 -> int # 7.5 cannot be converted to an integer without data loss
"8.2" -> int # "8.2" cannot be converted to an integer without data loss
4.3 -> bool # No more conversion from float to bool
"7 dogs" -> int # Non-blank trailing characters no longer supported
"3.14 pizzas" -> float # Non-blank trailing characters no longer supported
По поводу старых проектов, опять же, оригинальный анализ показывал, что если будет что-то отавливаться, то с большой вероятностью это указывает на место где есть баг.
One such company is the Canadian e-commerce giant Shopify, whose build system automatically > installed a Ruby gem named shopify-cloud only a few hours after I had uploaded it, and then tried > to run the code inside it. The Shopify team had a fix ready within a day, and awarded a $30,000 > bug bounty for finding the issue.
Another $30,000 reward came from Apple, after the code in a Node package which I uploaded to > npm in August of 2020 was executed on multiple machines inside its network. The affected projects appeared to be related to Apple’s authentication system, externally known as Apple ID.
Ну то есть не стоит делать какие-то выводы, когда документ в статусе черновика. И даже обсуждать его немного некорректно.
Вот кусок моей переписки с одним из участников core-команды:
The "Request for comments" part of an RFC only applies once it has
actually been published. While it is in draft, and the author is still
working on it, it's usually trivially easy to shit on the RFC and
point out all the problems with it, which is hugely discouraging to
RFC authors.
В каком-то смысле это даже сыграло в плюс, потому что теперь для кода будет полноценно использоваться GitHub и это удобнее.
Расмус на конференциях положительно высказывался про файберы. Возможно, он имел в виду предложение от Дмитрия https://wiki.php.net/rfc/fiber А сейчас я не видел его сообщений в internals. Были такие?
Расширение имеет же историю за плечами, ему года 3 минимум.
Если изучить глубже любой популярный язык, то выясняется, что в каждом есть свои "дыры" и "заплатки". В Java так особенно.
Процитирую Страуструпа:
А алгебра в тайпхинтах не перебор?
Вот это вроде ничего выглядит https://github.com/goetas-webservices/soap-client
Есть у вас какой-то пример кода? Давайте его вместе рассмотрим. Хочется разобраться.
Цитата странная, согласен, но в предложении говориться как раз об обратном. Там речь о том, чтобы убрать strict_type, но запретить многие неявные преобразования по дефолту. Например вот такие:
По поводу старых проектов, опять же, оригинальный анализ показывал, что если будет что-то отавливаться, то с большой вероятностью это указывает на место где есть баг.
А что думаете по поводу пунктов https://github.com/Girgias/unify-typing-modes-rfc#advantages-of-a-unique-typing-mode ?
А что именно недоумение вызвало? В посте так и написано:
Вы правы, поправил, спасибо.
Планируете публиковать ваше исследование и методологию? Было бы интересно сравнить.
Думаю, предупреждение добавить было бы хорошо. За статьи по инамам и эту спасибо!
Это понятно, просто черновиков много https://wiki.php.net/rfc#in_draft. Этот RFC официально еще не предложили. Вот когда станет "under discussion", тогда значит рассматривается.
Ну то есть не стоит делать какие-то выводы, когда документ в статусе черновика. И даже обсуждать его немного некорректно.
Вот кусок моей переписки с одним из участников core-команды:
Это пока черновик, то есть он даже не обсуждался. Думаю в 8.1 маловероятно.
Если самый быстрый, то значит, что заслуживает внимания.
А вы текст дайджеста читали? Во втором параграфе описания указано зачем это в дайджесте.
+ многим просто удобнее через var_dump, потому что быстро и ничего настраивать вообще не надо.
Пишут и показывают еще как :-)
https://t.me/phpdigest/204
https://habr.com/ru/post/535308/
https://youtu.be/mvjj_YX_BqQ?t=539
Если коротко, то сейчас как никогда хорошие шансы, что добавят.