Простой пример: если на странице в счётчике просмотров красуется «NaN», это неприятно, но не фатально. Или было бы лучше, если из-за такой ошибки вся страница становилась нефункциональной?
С другой стороны, скажу честно, в моей нынешней практике незамеченные баги, вызванные несоответствием типа — редкость. При условии, что в нужном месте производится проверка isFinite() (кстати, NaN может случиться и не только от приведения типов), аргументы (при необходимости) явно приводятся к конкретному типу, и сравнивание производится только через === за исключением == null.
В JS, кстати, тоже если ты присвоил foo = 42, то оно там так и останется лежать в виде числа, пока этой переменной не присвоишь что-нибудь другое. Даже после foo + "bar".
Только не подумайте, что придираюсь по мелочам, вот тут я не понял немного.
'33.4' + 1 == 34.4 // мы видели не все...
На выходе получится '33.41', поведение такое же, как и строчкой выше («если хотя бы один операнд — строка, складываем как строки»), чего тут неожиданного?
Собственно, да.
А если есть необходимость сначала использовать require('fs').stat(), где коллбек вызывается с (int err, object result), а затем какой-нибудь megaLib.doJob(), вызывающий коллбек с (object result)? Насколько я понял, итератор поперхнётся, приведя result к boolean и получив true.
А как же потом программно обрабатываются нажатия этих клавиш? Они определяются как геймпад, а затем вручную в каком-нибудь ниндзя-трейдере или есигнале маппятся на действия?
Буквально неделю назад писал свой арканоид (вернее, «арканоидо-оид», потому как управление другое) по правилам js1k. Выкладывать на хабр не стал, не думал, что кого-то заинтересует, видимо, зря.
Но сейчас, с позволения хабровчан, скромно оставлю ссылку: демо, код.
Вот-вот, «не в ущерб». Похожая ситуация: из IPv6 убрали контрольную сумму за ненадобностью. IP, более низкий уровень, уже считает контрольную сумму пакета, и незачем считать её дважды. Так и тут, зачем принуждать пользователей использовать SSL, если эта задача уже решена на более низком уровне?
И вообще, HTTP — протокол 7 уровня OSI, а SSL — 6-го (если я ничего не путаю). За каким чёртом HTTP должен знать, о том, какой более низкий слой его обеспечивает? Это что, чтобы сделать GET / HTTP/2.0 на localhost, мне нужно будет SSL поднимать?
Безусловно, IP используется не только для HTTP, но ведь и использовать IPSec для всех-вообще соединений никто не требует.
Ближайшее будущее, повсеместно наступил IPv6. Любое оборудование, поддерживающее IPv6, должно (ранее «MUST», сейчас «SHOULD») поддерживать IPSec для шифрования на сетевом уровне.
Поверх этого работает HTTP/2.0, и у него обязательно включен SSL, который используется для шифрования на уровне представления.
Вопрос: зачем столько шифрования, и когда вебостроители будущего договорятся, наконец, друг с другом?
Необязательные аргументы в середине списка всё-таки не самая удобная вещь. Как по мне, гораздо удобнее передавать опциональные параметры в виде хеша (объекта):
Foo.prototype.useWithBar(barInstance, options) {
if (options) {
var baz = options.baz;
var quux = options.quux;
}
/* ... */
}
С другой стороны, скажу честно, в моей нынешней практике незамеченные баги, вызванные несоответствием типа — редкость. При условии, что в нужном месте производится проверка
isFinite()(кстати, NaN может случиться и не только от приведения типов), аргументы (при необходимости) явно приводятся к конкретному типу, и сравнивание производится только через===за исключением== null.foo = 42, то оно там так и останется лежать в виде числа, пока этой переменной не присвоишь что-нибудь другое. Даже послеfoo + "bar".На выходе получится
'33.41', поведение такое же, как и строчкой выше («если хотя бы один операнд — строка, складываем как строки»), чего тут неожиданного?А если есть необходимость сначала использовать
require('fs').stat(), где коллбек вызывается с(int err, object result), а затем какой-нибудьmegaLib.doJob(), вызывающий коллбек с(object result)? Насколько я понял, итератор поперхнётся, приведя result к boolean и получив true.Но это, наверное, читерство.
Это не особенность JS как такового, а типа Number (который double).
Number.MIN_VALUEравен 5×10-324,1 / Number.MIN_VALUEпо-идее должен бы быть равен 2×10323, но это число слишком большое.А наоборот — пожалуйста, точности хватает.
Подробнее о том, почему в отрицательную сторону экспонента немного «вместительнее» — на википедии.
*UPD:* Поправил пример
npm install scryptпод win7 — это для меня было задание #0.Но сейчас, с позволения хабровчан, скромно оставлю ссылку: демо, код.
И вообще, HTTP — протокол 7 уровня OSI, а SSL — 6-го (если я ничего не путаю). За каким чёртом HTTP должен знать, о том, какой более низкий слой его обеспечивает? Это что, чтобы сделать
GET / HTTP/2.0на localhost, мне нужно будет SSL поднимать?Безусловно, IP используется не только для HTTP, но ведь и использовать IPSec для всех-вообще соединений никто не требует.
Поверх этого работает HTTP/2.0, и у него обязательно включен SSL, который используется для шифрования на уровне представления.
Вопрос: зачем столько шифрования, и когда вебостроители будущего договорятся, наконец, друг с другом?
Достаточно наглядно и не нужно помнить, что четвертый аргумент можно передать третьим, но при этом нужно в качестве второго указать второй, третий, либо null.
(см. также thecodelesscode.com/case/104)
Опять же, в ES Harmony это будет выглядеть намного опрятней: