Нативные прототипы против $ .extension ()

Question

На работе мы используем jQuery. Вскоре после того, как мы начали его использовать, я увидел, что пара разработчиков добавляет функции в файл jquery-extensions.js. Внутри я нашел целую кучу методов, добавленных к $, которые по сути равны статическим методам в jQuery. Вот несколько из них:

$.formatString(str, args) {
    ...
}

$.objectToArray(obj) {
    ...
}

Etc. Никто из них на самом деле не использует ничего общего с jQuery . Это показалось мне странным.

В конце концов нам потребовалась функция в нашей библиотеке для локализации дат. Моим решением было создать:

Date.prototype.toLocaleDate = function() {
    ...
}

Date.parseLocalDate = function() {
   ...
}

Вскоре после этого ко мне приходит старший разработчик и спрашивает меня, что я делаю. Он говорит мне, что здесь, где я работаю, мы не создаем прототипы, потому что они злые. Единственными причинами, которые он привел, было то, что они в основном плохие языковые возможности, потому что их «можно злоупотреблять» и что сбивает с толку просмотр прототипов (например, откуда я знаю, что новый Date (). ). Используя $.formatString(...) вместо "blah blah".formatString(...), мы ясно понимаем, что все, что с $, не является частью собственного JavaScript.

Эти причины кажутся немного глупыми, но я предложил компромисс, чтобы он не должен был помнить, был ли метод прототипом - префикс имени прототипа функции с $:

String.prototype.$format = function() {
    ...
}

"blah blah".$format(...);

Это было быстро отклонено, и теперь мне нужно везде добавлять эти функции $ .myPrototypeAsAFauxStaticMethodOnjQuery ().

Я единственный, кто считает эту практику глупой?

Answer 1

Споры о родных прототипах немного устали, с обеих сторон есть обоснованные пункты, я постараюсь обобщить их в надежде, что будет полезно увидеть общую картину.

против Нет необходимости расширять собственные прототипы. У вас есть все, что вам нужно.
pro Стандартная библиотека JS крайне мала. Массивам и строкам не хватает многих жизненно важных функций.

contra Используйте функции или свои собственные "пространства имен".
pro Методы, подобные foo.trim(), в гораздо большей степени соответствуют духу языка, чем функции, подобные org.blah.trim(foo). В javascript все является объектом, и пусть так будет.

contra Собственные объекты JS «зарезервированы» для разработчиков языка. Наши методы могут случайно переопределить недавно добавленные встроенные модули.
pro Открытые объекты - отличная особенность, и было бы глупо не использовать их. Новая версия Javascript - это не то, что происходит каждый день, и дополнения к стандарту хорошо известны заранее.

contra Расширение нативных прототипов сбивает с толку, потому что нет никакого различия между нашими и нативными методами.
pro Стандартная библиотека JS небольшая и хорошо документирована. Мы, разработчики javascript, должны знать имена нативных методов.

contra Расширение прототипов может привести к конфликтам пространства имен.
pro Да, но это может происходить и с глобальными функциями или с хорошо известными глобальными объектами (например, $).

contra Пользовательские методы перечисляются.
pro Да, но есть hasOwnProperty на помощь. Оберните его в свою собственную функцию перечисления и прекратите использование сырых циклов for..in с объектами.

(не реальный ответ, следовательно, CW)

Answer 2

1. Старшие звания часто переоценивают.
2. Есть много людей, которые не понимают наследование прототипа.
3. Хотя расширение прототипа собственных объектов JavaScript является законным, не делайте этого. Вы рискуете столкнуться с фреймворками.
4. Не имеет смысла перехватывать $ для утилит не-jQuery. Почему бы не использовать собственное пространство имен компании? Если вам нужно быть кратким, используйте $$ и т. Д.

Answer 3

Я думаю, что это не глупо! Но прототип красивее! Но опять же, кого волнует красота?Ваш код в конечном итоге будет страшным и будет сосать , но если он хорошо документирован и соответствует , вам никогда не придется думать об этих проблемах!