отвратительно
Почему?
"2"+"2" идет работа со строками, результат 22, а вот дальше "22"-"2" уже идет как работа с числами и хрен его поймет этот JS когда и с чем он решит работать
вроде всё понятно.
если сложно - не пиши такой код, сам приводи типы к нужным тебе.
если сложно - не пиши такой код, сам приводи типы к нужным тебе.
Автоматическое приведение типов - зло.
Обидно, что оно даже в C/C++ есть.
Я знаю как это работает. Вопрос был в том, почему "отвратительно"?
ты сейчас серьёзно? т.е. выбор ядра типа переменной между строкой и интом (и т.д.) идет реально РАНДОМНО???
вполне себе слева направо
последнее смешно
Это охуенно
Нет, не рандомно, минус - исключительно арифметическая функция, потому аргументы переводятся к типу «число»
По мне лучше получить ошибку типа "operator '-' cannot be applied to two 'String' operands", чем это.
теперь дошло -_-
не умеет в преобразования типов
Как раз, в том и проблема, что js умеет в неявное преобразование типов и порой за этим бывает сложно уследить. Вот если бы типизация была жесткой - многих проблем удалось бы избежать.
Frim не умеет в преобразования типов. с JS всё хорошо, не нужно жесткой типизации. если сильно хочется - есть TS.
>>с JS всё хорошо
Настолько хорошо, что люди придумывают 100500 фреймворков на каждый чих чтобы сделать его еще лучше!
А если серьезно: при нормальной архитектуре, скажем хотя бы MVVM и без лишних костылей, работать с проектом действительно не больно/сложно. Но как только заходишь на територию "закинь пока просто форму с jquery" -- вот тут начинаются приключения с преоброзованием типов, суперпозиции this и потерей значений из-за совпадения имен переменных/полей. В статической типизации такие вещи частично отсекаются на этапе компиляции что делает говнокодинг менее болезненым (но все также беспощадным).
Настолько хорошо, что люди придумывают 100500 фреймворков на каждый чих чтобы сделать его еще лучше!
А если серьезно: при нормальной архитектуре, скажем хотя бы MVVM и без лишних костылей, работать с проектом действительно не больно/сложно. Но как только заходишь на територию "закинь пока просто форму с jquery" -- вот тут начинаются приключения с преоброзованием типов, суперпозиции this и потерей значений из-за совпадения имен переменных/полей. В статической типизации такие вещи частично отсекаются на этапе компиляции что делает говнокодинг менее болезненым (но все также беспощадным).
Увы, TS тоже не панацея от проблем с типами, так как на выходе у него обычный JS. На стыке с обычным JS всё может пойти по накатанной колее. Неоднократно сталкивался с ситуацией когда в какую-то либу передаёшь колбек у которого в аргументах, к примеру, не-null строка, то при его вызове тебе и null может прилетает, и undefined. И всё равно приходится проверять аргументы или менять сигнатуру. И исправлять такие косяки сложнее чем в просто JS коде.
Потому что в одном случае операция работает с обьектами как с стрингами, а в другом случае как с интами. Это неочевидно
Ну а как иначе в динамически типизируемых языках?
Ясное дело что никак, но это как бы есть их проблема: если в формулу a + b - c внезапно попадет string (скажем забыл привести значение вытянутое с hidden), то начинаются приключения с дебагом.
Поэтому, в любой непонятной ситуации, используй унарный +
Рофлите уже хоть с этого, а то угорать над слабой динамической типизацией это уже не модно.
https://www.destroyallsoftware.com/talks/wat
https://www.destroyallsoftware.com/talks/wat
Тут как раз всё логично, я думал будет помимо очевидного 20 какой нибудь 202, nil, undefined или ещё какая срань
Чтобы написать коммент, необходимо залогиниться