Всем привет.
Лазил по форуму... и наткнувшись на undefined в обсуждении вспомнил, что именно с переменными такого типа у меня были проблемы... начал пробовать, и вот воссоздал одну непонятку.

Мне интересно, к какому значению boolean приводится переменная undefined?



fff не выскакивает, хотя булева логика не предусматривает третьего варианта :). То есть получается автоматически undefined вообще не приводится к типу boolean? Ведь иначе одно из условий сработало бы :) А если я не ошибаюсь в документации я читал что undefined приводится к false (давно было... могу ошибаться).

В общем интересно, кто считает такое поведение нормальным, и как его можно объяснить в пределах концепции не типизированного языка (ведь на паскале например вопрос бы вообще не возник... там всё понятно... строка с ошибкой. Но тут!!!...)

Малыхин СергейВ приведенном примере true и false приводятся к object после этого сравниваются
имхо все логично и понятно

с какой стати переменная "a" должна приводится к boolean ?

JS очень прост не надо его усложнять =)



Ну и баян на эту тему =)

За ссылку спасибо. Некоторые моменты и правда улыбают ).

Так... хорошо... у нас boolean переменные при сравнении с объектами приводятся к типу object, а не наоборот... Мне кажется это неправильным, но у разрабов видимо были причины так сделать (или же я упускаю какой-то момент, который они не упустили).

Вот ещё интересное поведение:



Итак, undefined - это специальный объект. При сравнении двух переменных типа object мы получим true только в том случае, если обе переменные указывают на один объект (насколько я помню документацию js).
то есть, если мы получаем true при сравнении undefined==null, значит это один и тот же объект (в доказательство я сравниваю 2 одинаковых объекта и получаю false, как и ожидалось).
Но если это один и тот же объект, так почему при его обработке функцией typeof мы получаем разные значения? значит это разные объекты?!!!

Ну то есть интересно, как это сравнение даёт true, когда должно бы false. К какому типу приводятся тут объекты, что бы результат стал "истина"?

Малыхин СергейТы не сравниваешь два объекта =)

Первые {} скобки интерпретируются как блок кода ( фигурные скобки в JS не только создают объект но используются в выражениях например для ограничения блока кода if() {} <--- используются фигурные скобки )

т.е. ( {} = пустой блок с кодом = undefined ) == ( {} = object )

Вот тут Вы ошиблись :) не... может конечно что-то и интерпретируется не так, но по сути значения не имеет:



ровно тот же результат. Сравнение двух объектов даёт истину только тогда, когда переменные указывают на один и тот же объект :) потому прошлый вопрос остаётся в силе (так как если даже и хитрости в интерпретации есть (хотя не верю, но ладно), то их упускаем, так как на результат это не влияет, а про сравнение двух объектов я не ошибся).

Малыхин Сергей,

Насчёт скобок - проверено... Вы ошиблись. В данном контексте они не интерпретируются как блок кода, так как


Вообще с ошибкой вылетает :) Потому нет... Первые скобки как и вторые однозначно понимаются интерпретатором как пустой объект

Малыхин СергейБыл не прав поспешил с ответом =) в данном случае сравниваются два разных объекта оба пустые (т.е. у них одинаковое содержание).

Ссылки "a" и "b" указывают на разные объекты условие не может быть true .
Взять например C++ если там то же сравнить два указателя на одинаковые объекты находящиеся в разных областях памяти
то условие так же не может быть истинным.

Почему в JS должно быть по другому?

Наоборот ... так и должно быть... Мне не понятна логика поведения при сравнении undefined и null. То есть и то и другое является объектом (исходя из первого ответа). При том эти 2 объекта разные... Но при их сравнении получаем true (что полностью противоречит вышесказанному).

Вот этот вопрос был основным :) почему undefined==null на выходе получаем true?

krvsaПрограмёрпочему undefined==null на выходе получаем true?
Дык это "реальность данная нам в ощщущении"...
Д.ФлэнаганНесмотря на эти отличия, оба значения null и undefined, являются признакам отсутствия значения и часто являются взаимозаменяемыми. Оператор равенства == считает их равными. (Чтобы отличать их в программе, можно использовать оператор идентичности ===.) Оба они являются ложными значениями - в логическом контексте они интерпретируются как false.

Это цитата из книги...

Из цитаты интуитивно предполагается, что если "оба значения null и undefined, являются признакам отсутствия" даёт нам равенство, то и "Оба они являются ложными значениями" то есть сравнение каждого из них с false тоже должно давать истину :) Ведь все три значения являются ложными...

Потому так и не понятно чем контролировались разработчики, когда закладывали такую логику сравнения с undefined.
И почему приводим переменные при сравнении от более примитивного вида к более сложному. То есть зачем мы из boolean делаем объект Boolean?

если приводить от сложного к простому, тогда типы приводились бы так:
object -> boolean ... array -> string -> number -> boolean

Таким образом, при сравнении:
объект можно сравнить только с boolean констатируя факт присутствия/отсутствия объекта (true/false)

массив приводится к строке (по некоторой схеме сериализации)
строка приводится к числу как и сейчас: приведения начинается с первого символа и заканчивается на неприводимом символе или конце строки
число приводится к boolean, 0 = false, иначе true.

Как по мне, такая схема была бы очень логична. А потребности в undefined вообще бы не было (если честно не знаю зачем она сейчас есть). то есть любая не инициализированная переменная - это 0 (NULL или [] или "" или 0 (или "0") или false). То есть тип значения не имел бы при нестрогом сравнении, но по умолчанию можно было бы считать такую переменную NULL.

Тогда проверка if(a) проверяла бы:
1. Существует ли объект
2. Не пустой ли массив
3. Не пустая ли строка (или не "0[.0[0]]")
4. Является ли число нулём
5. Является ли булево значение истиной.

То есть меняется лишь то, что у строки появляется несколько пустых значений, которые при приведении превращаются в 0. Но это думаю не проблема :)

Ладно... пошёл искать литературу, где описываются нынешние правила приведения. и почему именно так :) А то в общем знаю, но что-то особенности приведения непонятны.

krvsaПрограмёрПотому так и не понятно чем контролировались разработчики, когда закладывали такую логику сравнения с undefined.
Дык понимать-то особо и не нужно.
Оно вот такое и все дела.

неее... так не пойдёт :) Мы же не заучки-ботаны, а программисты. Программировать, не понимая что пишешь - это же ад... Когда надо запомнить кучу нюансов, а не принцип работы в целом.

Представляете себе интерфейс программы, в которой "Файл->открыть" находится по пути "Открыть -> файл", а "Файл -> открыть проект" по пути "Открыть -> проект"

При том, что сохранение проекта так и осталось в меню "Файл". И новый проект и файл создаётся именно в разделе "Файл" (ну как основное меню разумеется). При этом "Файл -> выход" находится в "О программе -> выход" (ведь выход из программы вроде). А "недавние документы" находятся около "сохранить" а не "открыть" (ведь это недавно сохранённые документы).

То есть вроде как смутная логика есть, но из-за кучи исключений, меню приобретает недееспособный вид :)

не рубящий в кашеПотому что (null === undefined) === false, а (null == undefined) === true
Использовать (==) - дурной тон.

для нетипизированного языка, ничего не дурной... а наоборот это родное для js, python, php, etc.

я никогда не знаю точно к какому типу была приведена переменная после некоторого количества операций... я просто знаю, что в переменной записано число (пускай например так "123456"). То есть функция может возвращать числовой результат, но сама переменная может иметь тип string. И это достаточно часто так работает. Потому строгое сравнение вернёт false, когда предполагалось что вернётся true :)

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

не рубящий в кашеПрограмёрдля нетипизированного языка, ничего не дурной... а наоборот это родное для js, python, php, etc.

я никогда не знаю точно к какому типу была приведена переменная после некоторого количества операций... я просто знаю, что в переменной записано число (пускай например так "123456"). То есть функция может возвращать числовой результат, но сама переменная может иметь тип string. И это достаточно часто так работает. Потому строгое сравнение вернёт false, когда предполагалось что вернётся true :)

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

Упаси меня боже когда-нибудь поддерживать Ваш код. Тьфу-тьфу-тьфу.
авторВ переменной записано число (пускай например так "123456")
И что будет после ?


будет "1234561" и что? :) Если я работаю со строковым представлением числа, то часто так это и описываю (в документации... в комментах).

Давайте так... Функция, которая может возвращать числа, в разы превышающие размер int. Как вы будете их обрабатывать? А я очень просто... буду возвращать это число в виде строки (просто задокументировав особенность). А в коде спокойно буду нестрого сравнивать с number, и буду получать правильный результат... ну или с string, если и второе число тоже большое (дополняя до одинаковой длины). То есть если я сравниваю с обычным числом, то никаких дополнительных обработок не требуется :)

А как Вы это будете делать... И какой код будет легче поддерживать?

krvsa,

понимание... вся суть в понимании :) Ну это как... Всемирное тяготение... Для обычной жизни вполне достаточно знать что всё падает на землю.
Для инженера и физика так сказать низкого уровня, достаточно знать, что сила гравитации на поверхности Земли равна в среднем 9.81м/с^2.

Но для реально высокого уровня и правильного понимания (запуска спутников например) требуется знать сам закон всемирного тяготения. Иначе спутники будут падать или улетать в дальний космос, а не ложиться на орбиту

Для обычной хозяйки достаточно знать, что если добавить в тесто соду, то оно станет пышным и при жарке блинов такие блины не будут прилипать к сковородке... Но по-настоящему хороший и профессиональный повар должен знать химию... То есть он должен не просто знать что если сделать так, то будет так... а если так - то этак. Но он должен понимать сам принцип почему так... и соответственно принимать решения по смешению некоторых продуктов и предсказывать получаемый вкус.

Ну и так в любой профессии. Так что я не вижу смысла вообще что либо заучивать... Типа будет так и всё :) Нет... не всё... надо знать почему. Тогда и исключений не будет . В правильно понятом правиле исключений не бывает ;)

Малыхин Сергейимхо все правила приведения типов должны описываться в спецификации языка все остальное домыслы и повод для бесполезного холивара.
т.е. в описании языка должно быть четко описано равно ли пять литров десяти километрам =)

спецификация говорит, что при сравнении приведение типов не используется между парами:
undefined и (string, number, object, null, boolean)
null и (string, number, object, undefined, boolean)

также в спецификации не описано сравнение array == boolean и object == boolean. Точнее, второе описано в последнем правиле нестрогого сравнения (результат будет false в иных случаях, и это сошлось). Но вот первый вариант, при сравнении false==[], не подходит под это правило, так как результатом будет true.

Так что, разрабы просто описали отдельно условия (undefined==null) === true и ((undefined,null)==(string,number,object,boolean))==false
То есть вместо определённого чёткого правила сравнения, они описали 10 правил, которые состоят в том числе из 10 исключений (описанных выше). При том при описании, если я правильно понял, была допущена одна ошибка (я про false == []).

И после этого все статьи про js начинаются с "самый лучший, удобный и гибкий язык"

Ладно :) пока воздержусь от явного ругания данного языка. С радостью выслушаю аргументы в защиту (или описание в чём я ошибся).

спецификация js (нестрогое сравнений)1. If Type(x) is the same as Type(y), then
 If Type(x) is Undefined, return true.
 If Type(x) is Null, return true.
 If Type(x) is Number, then
  If x is NaN, return false.
  If y is NaN, return false.
  If x is the same Number value as y, return true.
  If x is +0 and y is −0, return true.
  If x is −0 and y is +0, return true.
  Return false.
 If Type(x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions). Otherwise, return false.
 If Type(x) is Boolean, return true if x and y are both true or both false. Otherwise, return false.
 Return true if x and y refer to the same object. Otherwise, return false.
2. If x is null and y is undefined, return true.
3. If x is undefined and y is null, return true.
4. If Type(x) is Number and Type(y) is String,
return the result of the comparison x == ToNumber(y).
5. If Type(x) is String and Type(y) is Number,
return the result of the comparison ToNumber(x) == y.
6. If Type(x) is Boolean, return the result of the comparison ToNumber(x) == y.
7. If Type(y) is Boolean, return the result of the comparison x == ToNumber(y).
8. If Type(x) is either String or Number and Type(y) is Object,
return the result of the comparison x == ToPrimitive(y).
9. If Type(x) is Object and Type(y) is either String or Number,
return the result of the comparison ToPrimitive(x) == y.
10, Return false.