Плохо ли изменять (дополнять) прототипы встроенных объектов JavaScript?

Question

[President42]

Прочитал на JavaScript Garden, что изменять прототипы встроенных объектов -- нехорошо. Тем не менее, Prototype.js это делает, например.
Действительно ли так плохо менять прототипы встроенных объектов? Я для фана пилю свою библиотечку, хотелось там свои методы (типа как $(element).on(event, action) в JQuery). В самом JQuery вроде эти методы добавляются в момент вызова $(), но с изменением прототипа было бы проще.

Answer 1

[Юрий Пузыня]

Ситуация более реалистичная:
Вы пишете библиотеку А и решили реализовать String.ptototype.toURL
Кто-то другой пишет библиотеку B и тоже реализует эту функцию.
Вы подключаете библиотеку B в свой проект и пытаетесь понять, почему написанная вами функция работает не так как задумано.

Answer 2

[Константин Китманов]

По-моему, оглушительный «успех» Prototype.js и Sugar.js хорошо говорит о том, как это здорово и полезно — срать в прототипы встроенных объектов.
Делать так можно только в том случае, если вы пишете полифилл для IE.

В самом JQuery вроде эти методы добавляются в момент вызова $()

Нет, там все просто. on это обычный метод в jQuery.prototype.
Путаницы добавляет несколько моментов: $ это jQuery, вызов $(selector) — это вызов new jQuery(selector), а $.fn — это ссылка на jQuery.prototype, ну и плюс неразбериха из-за того, что $ — это god-object и принимает на вход строку с селектором, строку с HTML, функцию, DOM-элемент(-ы) и черта в ступе.

Comments

[Евгений Петров]

Справедливости ради отмечу, что Prototype «срал» в прототип HTMLElement (Object => Node => Element => HTMLElement => ... ), не затрагивая нативных объектов JS.
Хотя ИМХО трудностей с полифиллами для IE с таким подходов куда больше, чем в том же jQuery.
А так, вы безусловно правы — ковырять прототипы в любом месте цепочки наследования занятие неблагодарное:)

[Константин Китманов]

Евгений Петров: ну последние версии точно это делали. Недавно был вопрос на эту тему (не смог найти, простите), Prototype.js переопределял Object#toJSON и т.д.

Трудности в IE в данном конкретном случае проистекали из-за того, что HTMLElement в старых IE был хост-объектом, а у них нету прототипа (или он read-only, уже не помню).

[Евгений Петров]

Константин Китманов: Я тоже не помню точно, но вроде Element в IE 8 и ниже был read-only в силу имплементации.
Прототип в этом объекте как бы есть, но расширить его невозможно стандартными методами. От Object он ничего не наследовал, равно как и методы прототипа от Function...

Я помню решения, которые с помощью HTC расширяли интерфейс, но для этого осуществлялся тупой проход по нужным элементам. Prototype реализовывал новые методы и свойства только при обращении к элементу.

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

[Константин Китманов]

Евгений Петров: > был read-only в силу имплементации
вот я и говорю, сходите по ссылке, почитайте про хост-объекты.

[Евгений Петров]

Константин Китманов: Это не совсем то:) К примеру, document — host-объект, но имеет расширяемый прототип, который прекрасно наследует от прототипа Object через прототип Node.
А вот Element в старых IE вообще сам по себе. Прототип есть, но не расширяем.
Порыскал на скорую руку описание, что можно, а что нельзя.

[Константин Китманов]

Евгений Петров: нет, это то. Дело в том, что хост-объект не обязан следовать спецификации. Но может и следовать, если вендор вменяемый:)

[Евгений Петров]

Константин Китманов: Так в спецификации вроде нет жёсткого требования:
Whether or not a native object can have a host object as its [[Prototype]] depends on the implementation.

Я правильно понимаю, что наследование прототипа Node от прототипа Object не есть обязательное условие имплементации? Или это стало де-факто стандартом у вменяемых вендоров, а не у [пауза] некоторых других [ироничная ухмылка]?

[Константин Китманов]

Евгений Петров: поскольку DOM — это просто набор интерфейсов (и может быть, по идее, реализован или проброшен в любой язык), то к спецификации ECMA-262 он не имеет никакого отношения (тем более, что это даже другая организация:)), поэтому неизбежно Node — это хост-объект.
Поэтому да, индусы, которым некогда/лень пробросили его как получилось, а нормальные вендоры позаботились, чтобы все было консистентно.

[Евгений Петров]

Константин Китманов: Индусы... Как же я не подумал о таком развитии событий?))
Ещё раз принесу извинения за оффтоп. Просто такие вопросы задаются часто, а поговорить с умным человеком получается несравненно реже.

[Константин Китманов]

Евгений Петров: спасибо:)

Answer 3

[Павел Малышев]

Отвечу не популярно и даже радикально. Расширение прототипов существующих объектов - это собственно основа наследования в языке. Поэтому полагаю, что с точки зрения "анатомии" самого языка такой подход более чем правильный.

Однако в реальной жизни это рождает больше проблем, чем дает решений. А методика "оборачивания" объектов, аля jQuery, выглядит более безопасно в целом и частности.

Вообще похоже что никто так и не разобрался как "готовить" прототипное наследование и какие у него преимущества. Поэтому js в итоге скатился на самопальные "конструкторы", а в новом стандарте теперь и классы.