("PHP" == 0) => true, зачем?

Question

[trickii]

Здравствуйте,


вопрос про саму операцию уже был в q&a: Типы в PHP. Разрыв шаблона. Ответ сводится к простому — «ПАТАМУШТА».


В кратце:
var_dump(&quot;php&quot; == 0); //true<br/>


Мой вопрос состоит, а зачем? В любом случае такое нестандартное поведение было реализованно с какой-то целью. Есть у кого реальные примеры использования этой фичи или встречи с граблями из-за нее?

Answer 1

[Алексей Сидоров]

Интересно, почему же не пустая строка приводится к нулю, хотя она должна, по крайней мере, приводится к единице?

Comments

[Yashin]

в строке ищется первое вхождение числа. если оно не найдено — получается 0

[trickii]

По разговорам, коллеги ожидают от такой операции, если перый символ число — то число, а если нет — false, exception, notice, но не преобразование без остановки скрипта.

[Алексей Сидоров]

Блин… ну ведь делали же си подобный синтаксис, почему же даже минимально си подобное поведение не сделали? В итоге имеем костыли вида ===

[gro]

Для каких целей делать интерпретируемый язык с си-подобным синтаксисом, да ещё и си-подобным поведением?

[Анатолий]

Неужели Вы ожидаете от слабо типизируемого интерпретируемого языка поведения компилируемого языка со строгой типизацией? Какой наивный.

Answer 2

[Борис]

давайте по пунктам.
1. В РНР нет строгой типизации. Это факт.
2. Из п. 1 следует, что типы будут приводиться автоматически в некоторых случаях.
3. Строка приводится к числу именно так: (int)«PHP»; // 0
(мне это кажется логичным)
4. Чтобы сравнить два разных типа, нужно один привести к другому. С этим тоже глупо спорить.
5. Вот тут, возможно, неочевидный момент — в РНР для этого строка приводится к числу. Это описано в документации.

Comments

[Анатолий]

Поддерживаю, нет строгой типизации, одна переменная может быть любого типа, отсюда и ексешпинов/ошибок/нотисов нет. А то что к числу так приводится приводится это уже другой вопрос. Я бы удивился если бы мне (int)«не число» возвращал один.

[trickii]

Вот и мои наблюдения сводятся к тому, что этот подход породил «условность» которую приходится учитывать и обходить, дабы не породить ошибок. Т.е. отзывов о том, что это очень удобно и я это пользую, гораздо меньше, чем отрицательных.

[Анатолий]

Назовите мне хоть одну отрицательную черту того что при приведении строки в число, при условии что строка не число возвращается ноль?

[shagguboy]

Я бы удивился если бы мне (int)«не число» возвращал один
(int) true — будет 1

Answer 3

[Владимир Чернышев]

Практическое применение:

Поле ввода, которое подразумевает числовое значение, например, сумма перевода. Пользователь вводит строку «тыща баксов». Нормальной валидации нет (почему — отдельный вопрос). Перевод уходит только если сумма больше нуля. Строка преобразуется в ноль и перевод не уйдёт. Если бы преобразовалась в 1 (true), то перевод бы ушел с не очевидной для пользователя суммой, минимум багофича. А ещё лучше в -1 (true true :) ) и вообще никакой валидации — перевод бы получился отрицательным — критический баг.

PHP, имхо, разрабатывался так, чтобы снизить число таких критических багов.

Comments

[soider]

Крайне хилое оправдание какое-то.

[knekrasov]

Завидую вашей фантазии.
А еще было бы клево, чтобы в таких случаях он бы эксепшн вываливал.

[Владимир Чернышев]

2soider: какое есть

2knekrasov: эксепшен в таком случае можно вывалить самому, а вот если неявное преобразование устраивает, то придётся его ловить, что, имхо, сильнее испачкает код, чем самостоятельная его генерация.

Answer 4

[edogs]

Ответ там был не «патамушта», а «потому что строковый тип приводится к числовому».
И тогда становится более понятной логика (хотя ее разумность все еще сомнительна).
Не забывайте, что php язык изначально простой для построения простых страниц. Оттуда там всякие штуки типа глобальных (что бы не усложнять себе жизнь $_GET) и автослешей (что бы не усложнять себе жизнь addaslashes ($_GET) при вставке в БД).
Практика? Например:
var_dump(«1 руб»==1);//true

Comments

[trickii]

Под «патамушта» я имел ввиду «такова реализация в языке», про то, что приводится к числу я знаю. У нас часть коллег пришил с питона и на фоне этого завязался спор. И с целью раздобыть конкретных фактов я обратился к Хабру.

[Алексей Ашурок]

Для этого и был придуман "==="
И дабы совсем исключить все неясности пользуйте явное приведение типов. Тогда все будут счастливы :)

Answer 5

[edogs]

А, по поводу граблей еще был вопрос.
Поищите одно из описаний уязвимости в phpbb, достаточно критичной. Там одна из проверок шла вида if($a==$b), при этом $b бралось из сериализованного массива, хранящегося в cookies у пользователя. Соответственно скрипт ожидал строковой переменной и сравнения вида «login»==«admin», а тут внезапно приходило число, и сравнение превращалось в «login»==0, после чего наступал эпик фэил. Ну, это не очень точный рассказ, просто суть к тому сводилась.

Comments

[trickii]

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

[edogs]

Противникам можете сказать, что разные языки для того и разные, что бы в них делалось хоть что-то по разному:) В php есть возможность пользоваться «функцией» автоприведения типов, если ее использовать не хочется — можно использовать === и все будет как в «обычных» языках. А кривые руки можно к любому языку приложить, даже к тому где нет «автоприведения».

Answer 6

[gro]

Здесь неоднократно дали правильный ответ — «строка приводится к числу», но почему так делается для многих даже правильно ответивших неочевидно.
Вообще всё просто — в $_GET и $_POST всегда строки, хотя некоторые переменные подразумеваются числовыми, из базы тоже зачастую даже числовые поля приходят в строковом виде, ну и одна из основных задач PHP — обработка текста (в том числе XML), где опять-таки приходится работать с числами в виде строк.
Поэтому строки и рассматриваются зачастую, как числа.

Comments

[shagguboy]

«строка приводится к числу», но почему так делается
для преобразования строки в число используется функция strtod(3), это описанно в разделе

[shagguboy]

String conversion to numbers, документации PHP. собственно поведение этой функции и определяет вот эту неразбериху.

Answer 7

[shagguboy]

>Мой вопрос состоит, а зачем?
пхп задумывался как язык с нестрогой типизацией. весьма нестрогой. так что это просто багофича языка.
>Есть у кого реальные примеры использования этой фичи
постоянно пишу что то типа
if($str){
…
}
else{
…
}

Comments

[shagguboy]

у того же Оракла например пустая строка равна null. точно такая же багофича.

[trickii]

if('php') echo 'true'; //true — ok есть строка
if('') echo 'true';" //false — строка есть, но пустая, пусть будет false
if('0') echo 'true'; //false — и строка есть и значение есть, а все равно false
Вот вполне реальный пример

[trickii]

Вообще я из практики заметил, что зачастую использование 1 и 0 как альтернативы true/false вполне себе вызывает такие ошибки, которые потом тяжело искать.

[shagguboy]

When converting to boolean, the following values are considered FALSE:
the boolean FALSE itself
…
the empty string, and the string «0»

Answer 8

[Strate]

var_dump("php" == 0); // true
var_dump((int)"php" == 0); //true
var_dump("php" == (string)0); //false

Answer 9

[trickii]

Вот, кстати, и пример граблей, буквально вчера нашли:
От сервиса получаем курс как число или "--" в случае отсутствия. Дальше был такой код:

$price = count($price) > 0 ? (float) str_replace(',', '.', $price[0]) : 0;


Который выполнялся неверно, т.е. "--" превращался в -0. Понятно что "--" здесь не в тему, но таковы реалии, сервис не наш. Что характерно (integer) дает просто 0.

Comments

[shagguboy]

все входящие переменные надо валидировать однако.