Переопределять методы прототипа XMLHttpRequest?.. Что это вообще за ужас здесь написан?
Вы можете объяснить, как коверкание прототипа конструктора связано с нативной проверкой формы?
Денис Инешин: Ну я и не спорю, что не нужно делить то, что делить не нужно:)
Однако, сама концепция множественных классов не есть вредная и часто используется.
Денис Инешин: Да тут JS совсем не причём. Впрочем, если вам удобно классифицировать именно так — не вопрос:)
Вот только формулировка «не нужно и даже вредно.» про множественные классы однозначно неверна.
Представим, что есть блоки, которые имеют несколько состояний, и эти состояния должны быть выставлены при формировании страницы на сервере.
Такая задача решается добавлением нескольких классов. А что же предлагаете вы?
Илья Шатохин: Так я и не создаю, и раза 3 спрашивал — зачем в литерале вставлять подобное?) Ты же ответил: «а кто ж знает, откуда топикстартер взял данные».
Да, я не все типы данных ставил в обработку. Спасибо за подсказку — пойду-ка модифицирую код.
Илья Шатохин: Разве я тебе не говорил про то, что так массивы создавать не нужно:)
Что же касается определения типа, мне нужно понять — можно ли его конкатенировать и сортировать. Как бы JSON.stringify тут совсем не причём.
А с каких пор JSON.stringify стал определяющим при определении того, как я могу работать с объектом?)
Строго говоря, свойства в массиве записываются как строки. Так что никаких разногласий тут нет. А то, что строка получилась не совсем привычного вида — дело восприятия:)
Bhudh: Потому что получился прототип в виде функции. Статические методы от Array мы получили в наследство, а про прототип Array никто и ничего не знает.
Илья Шатохин: Мне на днях пришлось грамотно определять тип объекта, вспомнил про диалог:)
Вот что вышло jsfiddle.net/petroveg/u4e21qd0
И без isPrototypeOf таки не удалось обойтись (на втором массиве это можно проверить).
Вы можете объяснить, как коверкание прототипа конструктора связано с нативной проверкой формы?