Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Продолжая тему wiki.php.net/rfc/string_to_number_comparison и неудачных примеров приведения типов в пхп, я выражаю свое согласие с вышеизложенными предложениями, они соответствуют моему виденью и нашли применения в моих ф-циях toInt(), toFloat().
Я хотел бы обсудить аналогичную проблему каста в Boolean и String. Я столкнулся со следующими примерами, которые считаю неудачными и планирую переопределить в своих функциях кастования типа. В них я разграничиваю входные данные на ожидаемые и не ожидаемые для каждого из приведений типа.
1) Случаи приведения типа в Boolean и моей ф-ции toBool().
1.1) Стандартный каст (bool)5, (bool)-1 производят true. Я не считаю, что это правильно. Да, мы можем ожидать «1», «0», «1.0», «0.0», " 1 ", " 0 ", как репрезентацию true/false значений. Но если приходит 5 или -1 — это скорее говорит об ошибке переданных данных, чем об удачной возможности воспользоваться «магическим» преобразованием из коробки пхп.
В моем случае toBool(5), toBool(-1) вернет Null значение, которое я возвращаю, в случае неудачной конвертации типа.
1.2) (bool)«1.0», (bool)«1», (bool), " 1.0 ", производят true, как и ожидается.
(bool)«0», производит false, как и ожидается.
Но «0.0», " 0 ", так же производят true, что мне кажется неверным, моя toBool(«0.0») вернет false.
1.3) (bool)«string» производит true, когда «string» не выглядит, как ожидаемое значение для булевого типа. В моем случае toBool(«string») возвращает null.
1.4) (bool)"" производит false, что тоже по-моему мнению не верно.
Похожий кейс обсуждается в статье для чисел, когда идет речь о сравнении (bool)(0 == ""), которое производит true, а предлагают сделать false.
Я считаю, что toBool("") должно возвращать null, но здесь у меня сомнения.
1.5) (bool)null производит false, когда я считаю, что должно производиться null. Мы ведь часто хотим иметь возможность сбрасывать булево значение в состоянии объекта, и присваивание null, как раз сбрасывает его. После, мы ориентируясь на факт, что значение сброшено (а не false), можем например загрузить значение по-умолчанию.
1.6) (bool)[1], (bool)[0] — производит true, а (bool)[] — производит false.
Я считаю, что массив — это не ожидаемое значение и не может быть преобразовано, значит надо вернуть null.
2) Случаи приведения типа в String и моя ф-ция toString().
В случае приведения типа в String, я вижу следующие сомнительные стандартные касты из коробки пхп:
2.1) Если (string)true производит «1», тогда почему (string)false производит "", а не «0»?
Я считаю, что true/false — булево значение не является ожидаемым значением для каста в стринг и в обоих случаях toString() должен вернуть null. Здесь меня терзают сомнения.
2.2) (string)[] — производит E_NOTICE ошибку: «Array to string conversion», в моем случае toString([]) вернет null.
3.1) Чтобы быть полным, хочу сказать, что я так же не считаю булевы значения, как ожидаемые для каста в числа, и toInt(true), toFloat(false) в моей парадигме произведут null
3.2) Аналогично с массивом, toInt([1]), toFloat([]) производят null.
Очень жду комментариев и мнений. Что я не предусмотрел? Наверняка, эти вопросы уже покрыты в какой-то библиотеке, куда мне следовало бы заглянуть, прежде чем описывать эти правила.
Я хотел бы обсудить аналогичную проблему каста в Boolean и String. Я столкнулся со следующими примерами, которые считаю неудачными и планирую переопределить в своих функциях кастования типа. В них я разграничиваю входные данные на ожидаемые и не ожидаемые для каждого из приведений типа.
1) Случаи приведения типа в Boolean и моей ф-ции toBool().
1.1) Стандартный каст (bool)5, (bool)-1 производят true. Я не считаю, что это правильно. Да, мы можем ожидать «1», «0», «1.0», «0.0», " 1 ", " 0 ", как репрезентацию true/false значений. Но если приходит 5 или -1 — это скорее говорит об ошибке переданных данных, чем об удачной возможности воспользоваться «магическим» преобразованием из коробки пхп.
В моем случае toBool(5), toBool(-1) вернет Null значение, которое я возвращаю, в случае неудачной конвертации типа.
1.2) (bool)«1.0», (bool)«1», (bool), " 1.0 ", производят true, как и ожидается.
(bool)«0», производит false, как и ожидается.
Но «0.0», " 0 ", так же производят true, что мне кажется неверным, моя toBool(«0.0») вернет false.
1.3) (bool)«string» производит true, когда «string» не выглядит, как ожидаемое значение для булевого типа. В моем случае toBool(«string») возвращает null.
1.4) (bool)"" производит false, что тоже по-моему мнению не верно.
Похожий кейс обсуждается в статье для чисел, когда идет речь о сравнении (bool)(0 == ""), которое производит true, а предлагают сделать false.
Я считаю, что toBool("") должно возвращать null, но здесь у меня сомнения.
1.5) (bool)null производит false, когда я считаю, что должно производиться null. Мы ведь часто хотим иметь возможность сбрасывать булево значение в состоянии объекта, и присваивание null, как раз сбрасывает его. После, мы ориентируясь на факт, что значение сброшено (а не false), можем например загрузить значение по-умолчанию.
1.6) (bool)[1], (bool)[0] — производит true, а (bool)[] — производит false.
Я считаю, что массив — это не ожидаемое значение и не может быть преобразовано, значит надо вернуть null.
2) Случаи приведения типа в String и моя ф-ция toString().
В случае приведения типа в String, я вижу следующие сомнительные стандартные касты из коробки пхп:
2.1) Если (string)true производит «1», тогда почему (string)false производит "", а не «0»?
Я считаю, что true/false — булево значение не является ожидаемым значением для каста в стринг и в обоих случаях toString() должен вернуть null. Здесь меня терзают сомнения.
2.2) (string)[] — производит E_NOTICE ошибку: «Array to string conversion», в моем случае toString([]) вернет null.
3.1) Чтобы быть полным, хочу сказать, что я так же не считаю булевы значения, как ожидаемые для каста в числа, и toInt(true), toFloat(false) в моей парадигме произведут null
3.2) Аналогично с массивом, toInt([1]), toFloat([]) производят null.
Очень жду комментариев и мнений. Что я не предусмотрел? Наверняка, эти вопросы уже покрыты в какой-то библиотеке, куда мне следовало бы заглянуть, прежде чем описывать эти правила.
От to*() функций ожидаешь, что они любой треш преобразуют в соответствующий тип. Поэтому возвращение null мне кажется странным. Теряется смысл этих функций, потому что придется каждый раз дополнительно делать проверку на null. Тогда уж кидать TypeError, по аналогии с https://wiki.php.net/rfc/consistent_type_errors
В этих функциях есть второй параметр, который определяет применяемую фильтрацию, и всегда можно установить поведение по-умолчанию, как и усилить правила фильтрации, напр, вместо F_INT, использовать F_INT_POSITIVE, F_INT_POSITIVE_OR_ZERO.
Эти функции не предназначены для валидации значений, а только для каста. Какие конкретно приведения в null вам кажутся странными? Почему toInt(null), toBool(null), toFloat(null), toString(null) производит null, я объяснил, мы хотим отличать неустановленное значение от 0, false, 0.0, "". Другие моменты, я тоже попытался обосновать.
Эти функции не предназначены для валидации значений, а только для каста. Какие конкретно приведения в null вам кажутся странными? Почему toInt(null), toBool(null), toFloat(null), toString(null) производит null, я объяснил, мы хотим отличать неустановленное значение от 0, false, 0.0, "". Другие моменты, я тоже попытался обосновать.
«Работает — не трогай». Это ж какой лютый гемморой будет переходить на 8-ку, если это все сделают. Кучи явных и скрытых багов в логике повылезает просто ото всюду. А все изза того, что у когото перфекционизм головного мозга.
Т.е. вы считаете, что (bool)«0.0» === true — это корректно, когда (bool)«0» === false?
Причем здесь перфекционизм? Инструмент должен работать однозначно и быть интуитивно понятным. Могу парировать, что у вас пхп головного мозга, раз вы бескомпромистно полагаетесь на правила кастинга, изобретенные специально для пхп и не повторяющиеся в других ЯП.
И я не понял, какие проблемы меня ждут после перехода на пхп8? Пожалуйста, разъясните.
Причем здесь перфекционизм? Инструмент должен работать однозначно и быть интуитивно понятным. Могу парировать, что у вас пхп головного мозга, раз вы бескомпромистно полагаетесь на правила кастинга, изобретенные специально для пхп и не повторяющиеся в других ЯП.
И я не понял, какие проблемы меня ждут после перехода на пхп8? Пожалуйста, разъясните.
Проблемы вас ждут из-за того, что в любом более-менее живом проекте ваш код — не единственный. Даже если допустить, что вы везде используете strict_types=1 и пишете исключительно корректный с точки зрения типов код, то ручаться за авторов всех библиотек, которые вы испольузете — невозможно.
Поскольку проблема будет возникать в рантайме и статически отследить такие регрессии будет практически невозможно, то велик шанс столкнуться с огромным количеством багов и неявного поведения ПО. Да, все можно исправить со-временем, но вопрос в том, кто за это время будет платить.
Поскольку проблема будет возникать в рантайме и статически отследить такие регрессии будет практически невозможно, то велик шанс столкнуться с огромным количеством багов и неявного поведения ПО. Да, все можно исправить со-временем, но вопрос в том, кто за это время будет платить.
Пожалуйста, приведите пример. Потому что мои варианты кастинга с фильтрацией, как раз нормализуют входящие значения, чтобы избежать проблем, описываемых вами. Я считаю, что они не способствуют появлению проблемы, а наоборот.
Я не понимаю, почему эти методы должны как-то вредно взаимодействовать с вендорским кодом. Они будут использоваться только в рамках нашей кодовой базы.
Я не понимаю, почему эти методы должны как-то вредно взаимодействовать с вендорским кодом. Они будут использоваться только в рамках нашей кодовой базы.
При чем здесь вы и ваша библиотека. Речь идет о предлагаемых для 8 версии изменениях, в которых прямо указано:
> This change to the semantics of non-strict comparisons is backwards incompatible. Worse, it constitutes a silent change in core language semantics. Code that worked one way in PHP 7.4 will work differently in PHP 8.0
> This change to the semantics of non-strict comparisons is backwards incompatible. Worse, it constitutes a silent change in core language semantics. Code that worked one way in PHP 7.4 will work differently in PHP 8.0
А много ли других ЯП позволяют переводить из string сразу в bool?
Что мешает выполнить цепочку преобразований (bool)(float)«0.0»?
Что мешает выполнить цепочку преобразований (bool)(float)«0.0»?
- К примеру в Golang strconv.ParseBool(«0.0») выбросит ошибку strconv.ParseBool: parsing «0.0»: invalid syntax.
- В ruby совсем такого нет. Можно строку перевести в float а затем производить сравнения и прочее («0.0».to_f), но сразу в boolean нельзя.
- Python print(bool(«0.0»)) позволит и выдаст true, НО что бы привести корректно нужно сделать цепочку преобразований print(bool(float(«0.0»))).
- JS Boolean(«0.0») тоже возвратит true. И снова нужно цепочкой преобразовывать Boolean(parseFloat(«0.0»))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP-Дайджест № 151 (25 февраля – 11 марта 2019)