Несколько сравнений с использованием типов PHP, таких как пустая строка и пустой массив, возвращают неожиданные результаты

Question

Несколько сравнений с использованием типов PHP, таких как пустая строка и пустой массив, возвращают неожиданные результаты

1

Тройной равный, я думаю, все понимают; мои сомнения касаются двойного равенства. Пожалуйста, прочитайте приведенный ниже код.

<?php
//function to improve readability
function compare($a,$b,$rep)
{
    if($a == $b)
        echo "$rep is true<br>";
    else
        echo "$rep is false<br>";
}

echo "this makes sense to me<br>";
compare(NULL,0,'NULL==0');
compare(NULL,"",'NULL==""');
compare(NULL,[],'NULL==[]');
compare(0,"",'0==""');

echo "now this is what I don't understand<br>";
compare("",[],'""==[]');
compare(0,[],'0==[]');
compare(0,"foo",'0=="foo"');

echo "if I cast to boolean then it makes sense again<br>";
compare("",(bool)[],'""==(bool)[]');
compare(0,(bool)[],'0==(bool)[]');
?>

Вывод:

это имеет смысл для меня

NULL==0 is true
NULL=="" is true
NULL==[] is true
0=="" is true

теперь это то, что я не понимаю

""==[] is false
0==[] is false
0=="foo" is true

если я брошу в boolean, тогда это имеет смысл снова

""==(bool)[] is true
0==(bool)[] is true

Я ожидал бы, что пустой массив будет "равен" пустой строке или целому числу 0. И я не ожидал бы, что целое число 0 будет "равно" строке "foo". Честно говоря, я не совсем понимаю, что делает PHP за кулисами. Может кто-нибудь, пожалуйста, объясните мне, что здесь происходит?

2Noob2Good 08 нояб. 2015, в 21:03

Источник

2

Не пытайтесь понять PHP, просто примите участие в изучении / обращении к произвольным таблицам правил: php.net/manual/en/types.comparisons.php .
Oliver Charlesworth 08 нояб. 2015, в 19:44
0

дубликат: stackoverflow.com/questions/80646/…
i am me 08 нояб. 2015, в 19:44
2

@John Джон, я думаю, твой предложенный дубликат неверен. Здесь вопрос состоит в том, почему ""==[] оценивается как false , несмотря на то, что в PHP правила свободной печати (я ожидаю, что приведение также вернет true). Я не помню, чтобы я видел это здесь раньше. Вы хотели бы открыть снова?
halfer 08 нояб. 2015, в 19:52
0

@3.14:3.14: см. Мой комментарий выше - я думаю, что вопрос заключается в том, как правила свободной типизации применяются к массивам. Я не вижу, что ваш предложенный дуп касается этой проблемы.
halfer 08 нояб. 2015, в 19:54
1

@Halfer Хэлфер Да. Я так и сделал.
John Conde 08 нояб. 2015, в 19:57
0

@OliverCharlesworth Спасибо за ссылку. Это очень полезно. Я не понимаю так много отрицательных голосов за то, что пытался понять, почему "" == [] ложно 0 == [] ложно 0 == "foo" верно. Может я что-то не так объяснил или название могло бы быть лучше ...
2Noob2Good 08 нояб. 2015, в 19:57
0

Возможный дубликат Является ли оператор == транзитивным в PHP?
Oliver Charlesworth 08 нояб. 2015, в 19:59
0

@2Noob2Good: 2Noob2Good: не беспокойтесь о голосах, они были, вероятно, просто потому, что люди думали, что их уже спрашивали (я не думаю, что это так, следовательно, мой голос).
halfer 08 нояб. 2015, в 20:12
0

@ 2Noob2Good: Могу поспорить, что вы не получите быстрых ответов на этот вопрос, так как это сложная тема! Если в течение двух дней не будет лучшего ответа, @halfer меня с помощью @halfer и я добавлю вознаграждение.
halfer 08 нояб. 2015, в 20:35
0

@halfer - Какие ответы вы ожидаете, помимо предложенного мной дубликата?
Oliver Charlesworth 08 нояб. 2015, в 20:41
0

Привет, Оливер. Просто прочитайте ваш предложенный dup прямо сейчас, и я не вижу, чтобы он явно имел дело с тем, почему пустой массив и пустая строка не равны при тестировании с == . Пользователь Nacht затронул этот случай в своем ответе, но кроме того, что «это зависит от того, что вы подразумеваете под равенством», объяснений здесь мало. Ответ, который я ожидаю, может кратко затронуть внутреннюю часть PHP, то есть, что разработчики ядра PHP намеревались реализовать.
halfer 08 нояб. 2015, в 21:07
0

@halfer: Но есть десятки возможных вопросов, которые соответствуют шаблону этого вопроса, все отвечают с "== не является переходным" и ссылка на эту страницу документа, все по сути дубликаты. Я сомневаюсь, что кто-либо может авторитетно ответить на то, что было предполагаемое поведение ...
Oliver Charlesworth 08 нояб. 2015, в 21:12
0

@Oliver Оливер, я ожидал бы, что разработчик ядра PHP или кто-то, знакомый с кодом C, сможет ответить на это. Я не уверен, что транзитивность является проблемой здесь, в любом случае: я думаю, что это связано с внутренними правилами приведения, где задействован массив. Я считаю, что этот вопрос достаточно отличается, чтобы оставаться открытым, но если сообщество закроет его пятью голосами, пусть будет так :-) .
halfer 08 нояб. 2015, в 21:17
0

@halfer: получайте удовольствие от реализации: github.com/php/php-src/blob/master/Zend/zend_operators.c#L1780 ...
Oliver Charlesworth 08 нояб. 2015, в 21:28
0

Отлично, Оливер, там есть начало другого ответа!
halfer 08 нояб. 2015, в 21:30
0

@OliverCharlesworth, а ты веришь, что это что-то жестко закодировано? Нет причин для этого? Я понимаю, что это не просто приведение одного типа к другому, как я ожидал ... Здесь есть более сложная логика или что-то действительно жестко закодированное? ...
2Noob2Good 08 нояб. 2015, в 22:09
0

Я думаю, что имеет смысл, что это ложно. С интуитивной точки зрения. [] является ссылкой на массив. Массивы имеют ограниченную информацию, такую как глубина, что сильно отличает ее от типа string или int. Даже если он не содержит информации, он имеет информацию о том, что он имеет глубину 0 уровней и т. Д. Кроме того, "" - это своего рода ссылка на строку, даже если она равна значению bool при сравнении. Так как он пуст. Но это не массив.
Björn3 08 нояб. 2015, в 22:22
0

@Oliver Оливер, согласен с вопросом "почему, учитывая кажущуюся непоследовательность, это так?" с акцентом на «почему», это хорошо. Знание того, почему с ним легче иметь дело. Источник - длинный уродливый список комбинаций, но без очевидной однородной структуры. Где-то в долгой истории PHP может быть (или не может) быть очень веская причина для этого. Если эта причина не может быть раскрыта, является ли правильный ответ, то «На данный вопрос нельзя ответить так, как никто не может вспомнить, или он просто эволюционировал таким образом, но попытка вернуться к нему сейчас сломает слишком много существующего кода»? Это правильный ответ SO?
Berniev 08 нояб. 2015, в 22:50
0

@Berniev: мы пытаемся сделать заголовки достаточно конкретными, чтобы люди могли понять, о чем идет речь, прежде чем щелкнуть по нему. Кроме того, у нас есть неписанное правило: если кто-то делает преднамеренное редактирование, он не отменяет его без консультации. Поэтому я откатил название редактирования здесь. Если вы сильно предпочитаете свой, вы бы пометили вопрос модератору? Затем они могут разрешить его так же, как если бы они изменили разногласия. Спасибо!
halfer 16 нояб. 2015, в 18:26
0

@halfer: Возможно, вы пропустили, что первоначальный вопрос был о трех случаях, один из которых не был связан с массивами. Ваше оригинальное редактирование заголовка, и действительно ваш ответ, кажется, пропускают это. Просьба пересмотреть, поскольку полезность вопроса и ответа шире, чем массивы. Кстати, мое изменение было проверено и одобрено. У меня не было (не?) Достаточно представителей, чтобы сделать это самостоятельно.
Berniev 16 нояб. 2015, в 23:58
0

@Berniev: качество обзоров здесь довольно сильно варьируется - ищите «рецензентов роботов» в Meta .
halfer 17 нояб. 2015, в 08:00
0

@Berniev: Берниев: в любом случае, я ценю ваши отзывы. Я не пропустил, что один из элементов не был массивом, нет - я не думал, что это центральная часть вопроса (если вы видите последний блок кода, с этим элементом больше не обращались). Тем не менее, я сделал правку, чтобы попытаться объединить тему вашей правки - это лучше? (Я хочу отличить этот вопрос от многих других вопросов, касающихся жонглирования - один раз он был закрыт как dup, и я думаю, что стоит его дифференцировать).
halfer 17 нояб. 2015, в 08:07
1

@halfer. прохладно. голосовать за мой ответ?
Berniev 17 нояб. 2015, в 12:27

Показать ещё 21 комментарий

Теги:

php

boolean

2 ответа

Ещё вопросы

Не пытайтесь понять PHP, просто примите участие в изучении / обращении к произвольным таблицам правил: php.net/manual/en/types.comparisons.php .
@John Джон, я думаю, твой предложенный дубликат неверен. Здесь вопрос состоит в том, почему ""==[] оценивается как false , несмотря на то, что в PHP правила свободной печати (я ожидаю, что приведение также вернет true). Я не помню, чтобы я видел это здесь раньше. Вы хотели бы открыть снова?
@3.14:3.14: см. Мой комментарий выше - я думаю, что вопрос заключается в том, как правила свободной типизации применяются к массивам. Я не вижу, что ваш предложенный дуп касается этой проблемы.
@OliverCharlesworth Спасибо за ссылку. Это очень полезно. Я не понимаю так много отрицательных голосов за то, что пытался понять, почему "" == [] ложно 0 == [] ложно 0 == "foo" верно. Может я что-то не так объяснил или название могло бы быть лучше ...
Возможный дубликат Является ли оператор == транзитивным в PHP?
@2Noob2Good: 2Noob2Good: не беспокойтесь о голосах, они были, вероятно, просто потому, что люди думали, что их уже спрашивали (я не думаю, что это так, следовательно, мой голос).
@ 2Noob2Good: Могу поспорить, что вы не получите быстрых ответов на этот вопрос, так как это сложная тема! Если в течение двух дней не будет лучшего ответа, @halfer меня с помощью @halfer и я добавлю вознаграждение.
@halfer - Какие ответы вы ожидаете, помимо предложенного мной дубликата?
Привет, Оливер. Просто прочитайте ваш предложенный dup прямо сейчас, и я не вижу, чтобы он явно имел дело с тем, почему пустой массив и пустая строка не равны при тестировании с == . Пользователь Nacht затронул этот случай в своем ответе, но кроме того, что «это зависит от того, что вы подразумеваете под равенством», объяснений здесь мало. Ответ, который я ожидаю, может кратко затронуть внутреннюю часть PHP, то есть, что разработчики ядра PHP намеревались реализовать.
@halfer: Но есть десятки возможных вопросов, которые соответствуют шаблону этого вопроса, все отвечают с "== не является переходным" и ссылка на эту страницу документа, все по сути дубликаты. Я сомневаюсь, что кто-либо может авторитетно ответить на то, что было предполагаемое поведение ...
@Oliver Оливер, я ожидал бы, что разработчик ядра PHP или кто-то, знакомый с кодом C, сможет ответить на это. Я не уверен, что транзитивность является проблемой здесь, в любом случае: я думаю, что это связано с внутренними правилами приведения, где задействован массив. Я считаю, что этот вопрос достаточно отличается, чтобы оставаться открытым, но если сообщество закроет его пятью голосами, пусть будет так :-) .
@halfer: получайте удовольствие от реализации: github.com/php/php-src/blob/master/Zend/zend_operators.c#L1780 ...
Отлично, Оливер, там есть начало другого ответа!
@OliverCharlesworth, а ты веришь, что это что-то жестко закодировано? Нет причин для этого? Я понимаю, что это не просто приведение одного типа к другому, как я ожидал ... Здесь есть более сложная логика или что-то действительно жестко закодированное? ...
Я думаю, что имеет смысл, что это ложно. С интуитивной точки зрения. [] является ссылкой на массив. Массивы имеют ограниченную информацию, такую как глубина, что сильно отличает ее от типа string или int. Даже если он не содержит информации, он имеет информацию о том, что он имеет глубину 0 уровней и т. Д. Кроме того, "" - это своего рода ссылка на строку, даже если она равна значению bool при сравнении. Так как он пуст. Но это не массив.
@Oliver Оливер, согласен с вопросом "почему, учитывая кажущуюся непоследовательность, это так?" с акцентом на «почему», это хорошо. Знание того, почему с ним легче иметь дело. Источник - длинный уродливый список комбинаций, но без очевидной однородной структуры. Где-то в долгой истории PHP может быть (или не может) быть очень веская причина для этого. Если эта причина не может быть раскрыта, является ли правильный ответ, то «На данный вопрос нельзя ответить так, как никто не может вспомнить, или он просто эволюционировал таким образом, но попытка вернуться к нему сейчас сломает слишком много существующего кода»? Это правильный ответ SO?
@Berniev: мы пытаемся сделать заголовки достаточно конкретными, чтобы люди могли понять, о чем идет речь, прежде чем щелкнуть по нему. Кроме того, у нас есть неписанное правило: если кто-то делает преднамеренное редактирование, он не отменяет его без консультации. Поэтому я откатил название редактирования здесь. Если вы сильно предпочитаете свой, вы бы пометили вопрос модератору? Затем они могут разрешить его так же, как если бы они изменили разногласия. Спасибо!
@halfer: Возможно, вы пропустили, что первоначальный вопрос был о трех случаях, один из которых не был связан с массивами. Ваше оригинальное редактирование заголовка, и действительно ваш ответ, кажется, пропускают это. Просьба пересмотреть, поскольку полезность вопроса и ответа шире, чем массивы. Кстати, мое изменение было проверено и одобрено. У меня не было (не?) Достаточно представителей, чтобы сделать это самостоятельно.
@Berniev: качество обзоров здесь довольно сильно варьируется - ищите «рецензентов роботов» в Meta .
@Berniev: Берниев: в любом случае, я ценю ваши отзывы. Я не пропустил, что один из элементов не был массивом, нет - я не думал, что это центральная часть вопроса (если вы видите последний блок кода, с этим элементом больше не обращались). Тем не менее, я сделал правку, чтобы попытаться объединить тему вашей правки - это лучше? (Я хочу отличить этот вопрос от многих других вопросов, касающихся жонглирования - один раз он был закрыт как dup, и я думаю, что стоит его дифференцировать).
@halfer. прохладно. голосовать за мой ответ?

Berniev · Answer 1 · 2015-11-08T22-55-00.000Z

Простой ответ заключается в том, что именно так php был разработан для работы.

Результаты хорошо определены в операциях сравнения документов и сравнительных таблицах.

A == сравнение между массивом (ваши первые два запроса) и строкой всегда приводит к false.

В сопоставлении == между числом и строкой (ваш третий запрос) строка преобразуется в число, а затем производится цифровое сравнение. В случае 0 == 'foo' строка 'foo' численно оценивается до 0 и тест становится 0 == 0 и возвращает true. Если строка была "числовой", например "3", результат в вашем случае был бы ложным (0 не равно 3).

Является ли дизайн "правильным" (что бы это ни значило), является спорным. Это, конечно, не всегда очевидно. Иллюстративный пример потенциальной ярости дебатов можно найти в Bug # 54547, где разработчики утверждают, что дизайн основан на истории php как на веб-языке, где все является строкой и должно быть оставлено в покое, а другие утверждают, что php " нарушает принцип наименьшего удивления ".

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

Читая этот отчет об ошибке, мне кажется, что есть шанс, что изменения могли быть внесены, но из-за агрессивной толпы, готовой злоупотребить основными разработчиками, было решено закрыть. Если ничего другого, это демонстрирует, как не поддерживать сообщение об ошибке ;-) .

halfer · Answer 2 · 2015-11-08T17-53-00.000Z

Как уже говорилось, правила автоматического каста PHP могут быть довольно сложными, и стоит использовать === если вы не знаете, что обе стороны будут одного типа. Однако я считаю, что могу объяснить это:

""==[] (returns false)

Исходная строка "" указывает, что сравнение будет строковым, и, таким образом, [] передается в строку. Когда это произойдет, правая часть сравнения будет установлена на слово Array. Поэтому вы делаете это сравнение:

"" == "Array" (returns false)

и, следовательно, false результат.

Изменение: полезный комментарий ниже вызывает сомнение в моем ответе с помощью этого примера с живым кодом. Мне должно быть интересно узнать, какие другие ответы предоставляются.

Я считаю, что это обоснование неверно: ideone.com/povYMk
Да, я тоже это попробовал. И на самом деле это как раз мой вопрос. Если я не могу понять, как работает ==, я не могу использовать его на 100% спокойно. Конечно, я всегда мог использовать ===, но иногда == действительно удобно. Если бы я мог предсказать результат, не глядя на таблицу, конечно ...
Это хороший тест @ Оливер, и у меня нет готового ответа на него. 0==[] меня тоже поставили в тупик. Интересно, происходит ли здесь какая-то проверка полупериода, для случая, когда одна сторона является массивом?
@ 2Noob2Good: да, согласно моему ответу, используйте === (или выполняйте явное приведение), если только вы не знаете, что обе стороны всегда будут одного типа.
То, что происходит, - то, что будут некоторые жестко закодированные правила под капотом. Авторы PHP добавили, что думают, что они сделают вещи проще, но на самом деле сделали семантику более сложной ...
Существует удобный график здесь . Я не ожидаю, что эти правила изменятся в ближайшее время. Свободное печатание может быть благословением ... и проклятием.
@ Берниев: спасибо, очень интересно. Я думаю, что нам нужно объяснение того, почему определенные комбинации жонглирования имеют такой результат. Я считаю, что, хотя люди не должны делать это сравнение без явного приведения, пустая строка и пустой массив должны быть практически равными, если тип игнорируется (они оба приводят к логическому значению false). Однако это не то , что происходит, так что я был бы заинтересован в том , что происходит.