Комментарии 23
Мы сканили в январе все доступные домены в интернете, порядка 250 млн штук доменов, из общего количества более менее работающих хостов в 295 млн (т.е. один и тот же сайт может работать на http, https, +www и т.п.) на вордпрессе работало 30.7 млн, что получается в районе 10%.
Интересно, откуда по интернету ходит число в 40% всех сайтов.
Мы сканили в январе все доступные домены в интернете, порядка 250 млн штук доменов
а они использовали:
For all our statistics we use the Alexa top 10 million websites, complemented by the Tranco top 1 million list.
Планируете публиковать ваше исследование и методологию? Было бы интересно сравнить.
почти три года назад писал на эту же тему habr.com/ru/post/413739
самому интересно узнать, что поменялось в сети
А начиная с PHP 8.1 встроенные функции тоже будут бросать TypeError
они будут бросать deprecation, а TypeError будет начиная с PHP 9:
- in PHP < 8.1 the null value will be silently coerced to either false, 0, 0.0 or “”.
- in PHP >= 8.1 a deprecation error is thrown, but the value is still coerced and the call still takes place.
- in PHP >= 9.0 a TypeError is thrown, consistent with the behavior of user-defined functions.
Спасибо за подборку. Вот это, правда, вызвало недоумение:
Почему нужно убрать strict_types
…
Приятного чтения.
Прочитал. Но не нашел нет причин, почему его нужно убирать. Да есть какой-то драфт, который в ближайшее время даже на RFC. А если и будет RFC, то не факт, что примут.
А что именно недоумение вызвало? В посте так и написано:
пока он не планирует его выдвигать в качестве официального RFC.
Я так и не понял, почему нужно убрать strict_types. Я его ставлю по всему проекту и в линтере в CI он у нас требуется обязательно. Поэтому вопрос не праздный, но ответа я на него не нашел.
А что думаете по поводу пунктов https://github.com/Girgias/unify-typing-modes-rfc#advantages-of-a-unique-typing-mode ?
- Smaller cognitive burden
- Too strict may lead to too lax
- Smooth integration with data sources
- No need for "namespaced declares" is removed as it is only needed for strict_types
Например, я не согласен с этим:
Most notably float to integer and string to integer or float conversions, conversions the engine can perform safely in coercive type mode.
Все эти неявные конвертации могут быть результатом ошибки.
Также я не согласен с изменением дефолта, ибо апгрейд старых проектов на новый пхп превратится в кошмарный сон.
Цитата странная, согласен, но в предложении говориться как раз об обратном. Там речь о том, чтобы убрать 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По поводу старых проектов, опять же, оригинальный анализ показывал, что если будет что-то отавливаться, то с большой вероятностью это указывает на место где есть баг.
А я не хочу, чтобы убирали strict_types, потому что я не хочу иметь неявное преобразование "8" => 8 или "8.2" => 8.2. И даже 8.2 => 8 (int). Просто потому, что это РАЗНЫЕ типы. Скажем, если работать с elasticsearch, то внезапно окажется, что такой бардак может вести к неприятностям (да, я знаю, как их обходить, и всё же это хождение по граблям).
Есть у вас какой-то пример кода? Давайте его вместе рассмотрим. Хочется разобраться.
Примера кода нет, но представьте, что у вас на основе данных генерируется схема данных в том же Elasticsearch. Если вы пошлете в него сначала int (схема сгенерировалась), а потом float (в существующую схему), то всё, у вас неприятности.
Или если вы работаете с сервисом, который строго валидирует входные данные, а для вас — программиста на PHP — не критично, послали ли вы строку или int, то рано или поздно проблемы в коммуникации с сервисом гарантированы. Можно, конечно, гарантировать тип на входе в функцию, можно иметь некий нормализатор и так далее. Да только выльется это в дурные привычки (которых у программистов на PHP и без того много), а в конечном итоге такие вольности приведут к хождению по граблям. И опять понадобится strict_types.
Короче, сколько себя помню — столько эту функцию хоронят и отговаривают от нее, но что-то вот уже и РНР8 и там она что-то даже не deprecated — наверное разрабы языка таки что-то понимают…
Использовать можно, главное понимать зачем и как это работает.
Empty помогает сократить написание, ибо сразу на существование и непустое значение проверить можно. Внимание, нужно помнить про false, 0, ибо empty(false), empty(0) вернёт true, особенно помнить про 0).
Например, если нужно и на false, и на null сразу проверить, чтобы дважды не писать, можно в empty обернуть, или с пустым и неопределённым массивом/объектом также. Одна проверка вместо двух.
Зачем писать isset($arr) && count($arr) > 0, если можно написать !empty($arr).
Аналогично вместо isset($bool) && $bool === true можно !empty($bool)
Вывод: используйте, если понимаете, как это работает
Вот это самая большая проблема empty: var_dump(empty('0')); // => bool(true).
Я даже натыкался на случай, когда это вело реально к неожиданному для разработчика поведению, и — как следствие — к багу в продакшне.
а затем еще раз освежите в памяти нестрогое сравнение различных типов с булевым false, и тогда все станет прозрачно и понятно:
var_dump(
(bool) null, // false
(bool) '0', // false
(bool) '1', // true
(bool) '', // false
(bool) 0, // false
(bool) 1, // true
(bool) [] // false
);
PHP Дайджест № 199 (8 – 22 февраля 2021)