Comments 21
Весь язык как та картинка
А что из этого нельзя было прочитать в спецификации языка?
Никогда не понимал людей, который плодят подобную писанину, в то время, как спецификация исчерпывающе все объясняет. Мало того, все то-же самое очень детально описано в трудах авторов типа Николаса Закаса и Кайла Симсона.
А я не понимаю тех, кто тыкает в спецификацию. Вы когда машину покупаете — читаете всю 1500-страничную спецификацию? Или садитесь и едете? Вы уверены, что авторы всех пакетов в npm по всей цепочке зависимостей, которые вы используете, читали спецификации? Вы читаете код каждого пакета и зависимостей, которые используете? Язык, который не бьёт по рукам, когда программист пытается сделать говно в итоге приводит к тому, что дятел влетает в форточку и все взрывается. Можно же сделать интерпретатор со строгой динамической типизацией, который запретит неявное приведение типов. И массив со строкой не даст сложить и покажет, насколько глубоко все испорчено уже.
Я читаю всю книжку после покупки машины, просматриваю большинство npm модулей, которые ставлю себе в зависимости, но не могу не согласиться, что спеки читает далеко не каждый. Совсем далеко. И прочитать такую статью о самом главном по топику легче, чем закопаться в спеку. Поэтому статья очень даже хороша и к месту.
Если для понимаю таких вещей нужно лезть в спецификацию каждый раз, то язык спроектирован не очень хорошо.
Почему же каждый раз? Достаточно 1 раз понять, как это работает и жить счастливо. Что в статье есть из правил?
1. Бинарный оператор "+" с не строками пытается выполнить операцию сложения
2. Если хотя бы 1 операнд строка — конкатенцаия
3. При неявном приведении разных типов всё сводится к строкам.
Вот как бы и всё кажись? Там реально не всё так сложно, если понять основы.
1. Бинарный оператор "+" с не строками пытается выполнить операцию сложения
2. Если хотя бы 1 операнд строка — конкатенцаия
3. При неявном приведении разных типов всё сводится к строкам.
Вот как бы и всё кажись? Там реально не всё так сложно, если понять основы.
Как вы относитесь к неявному приведению типов в JavaScript?
Всё это, конечно, прикольно и, наверное, кому-то удобно. Но лучше бы в языке было поменьше вещей, способных удивить в самый неожиданный момент.
Как ни странно — согласен. Неявное приведение типов в большинстве случаев работает логично, но есть
"" == 0
и оно портит картину в случаях, когда a.toString() == ""
Если бы было isNaN("") — сюрпризов было бы в разы меньше.
"" == 0
и оно портит картину в случаях, когда a.toString() == ""
Если бы было isNaN("") — сюрпризов было бы в разы меньше.
поэтому вместо isNaN(x) я пользуюсь конструкцией x !== x. Точно также проверяет на nan, но не приводит типы.
Если бы было isNaN("") — сюрпризов было бы в разы меньше.
В чем логика? Ведь строка — это не NaN. Вы топите за убирание неявного приведения, а потом просите неявное приведение?
Вы топите за убирание неявного приведения
Простите, в каком месте?
Я ничего не имею против неявного приведения типов, мне не нравится, что пустая строка при приведении к числовому типу даёт 0, а не NaN.
Пустая строка — это число?
Это не число, но это и не NaN. Поймите, что NaN — это особое значение, результат математической операции, а не любое не-число.
NaN — «Not a Number». И NaN не является результатом корректной математической операции.
NaN — это спецзначение типа данных IEEE754.
Как вам выше сказал Zenitchik — это не любое «не число». Если его заодно подтянуть под кое-какие нюансы ЖС — вы еще больше запутаете ситуацию.
Про то, что это спецзначение стандартизированного числового типа данных, принятое для обозначения не-числа, я знаю.
Про то, что множество NaN'ов не обозначает (в совокупности, т.е. хотя бы один NaN не обозначает) любое конкретное «не число» — это спорное замечание.
Доступа к тексту стандарта у меня нет (есть подозрение, что он вообще платный), но на многих ресурсах, включая, например, документацию MDN , я вижу следующее (или аналогичное):
Ещё прекраснее описанное там же отличие между поведением isNaN() и Number.isNaN().
Хоть убейте, это нельзя назвать логичным и последовательным дизайном языка.
Про то, что множество NaN'ов не обозначает (в совокупности, т.е. хотя бы один NaN не обозначает) любое конкретное «не число» — это спорное замечание.
Доступа к тексту стандарта у меня нет (есть подозрение, что он вообще платный), но на многих ресурсах, включая, например, документацию MDN , я вижу следующее (или аналогичное):
It is the returned value when Math functions fail (Math.sqrt(-1)) or when a function trying to parse a number fails (parseInt(«blabla»)).
Ещё прекраснее описанное там же отличие между поведением isNaN() и Number.isNaN().
Хоть убейте, это нельзя назвать логичным и последовательным дизайном языка.
Функция parseInt, после разбора переданного ей аргумента, округляет полученные числа.
…
Эта функция неправильно работает с очень большими числами, поэтому её не следует рассматривать в качестве альтернативы функции Math.floor (она, кстати, тоже выполняет приведение типов).
Оба утвержедния не соответсвует истине. Фнукция отбрасывает все что не соответсвует формату целых чисел то есть например начиная с десятичной точки. То есть фактически отрасывает дробную часть.
Аналогичено и с большими числами. 1е2 можно спорить о том насколько большое это число. но точно 1 получится потому что там с «е» начинается нарушение формата целого числа
Шёл 2018ый год, люди всё так же сокрушались о особенностях JS, вместо того, чтобы прочитать спеку, запомнить пару мелочей, смириться и перестать.
Sign up to leave a comment.
[1] + [2] — [3] === 9!? Исследование внутренних механизмов приведения типов в JavaScript