Расширение прототипов встроенных обьектов: хорошо или плохо?
 

Неоднократно слышал от уважаемых мною людей, что Prototype.js — некошерно, потому что изменяет прототипы встроенных обьектов.
Недавно почитал про MooTools, и оказалось, что они тоже используют этот подход, более того, предоставляют удобный интерфейс для расширения прототипов.

И у меня закрались сомнения.

Действительно ли плохо менять встроенные прототипы? Чем это плохо, кроме того, что возможно, при подключении еще одного фреймворка, возникнут конфликты?

Какие подводные камни?

Prototype не кошерно, потому что они JavaScript не знают :) Смотрите, например, реализацию метода each для массивов.

По теме: юзаю активно.

Лень, если честно, поверю на слово:)

А какой фреймворк (если есть)? И какие трудности возникали, если возникали?

Спасибо.

Во фреймворках, как правило, все для жизни имеется, там что-то дополнительно расширять не надо. В pure скриптах расширяю. Там, где требуется максимальная изолированность, разумеется не расширяю.

Если я использую сторонний фреймворк, я его всегда могу пропатчить/удалить в случае чего. Если я пишу фреймворк, который будет использоваться сторонними разработчиками, проблемы, разумеется могут быть, но не у меня :)

Kolyaj, удалить? а если уже полмегабайта скриптов написано с расчетом на этот фреймворк?

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

Kolyaj, это-то очевидно.

А какие еще могут возникнуть проблемы?

hogart, пока нельзя задавать внутреннее свойство {DontEnum} добавляемым методам/свойствам, не советуют расширять Object.prototype и Array.prototype. Причина: оператор in найдёт эти свойства в "пустых" объектах. В остальном - это в идеологии языка, поэтому - смело можно расширять всё, что захочется.

А по массивам не надо бегать for-in, у них есть (везде, кроме ИЕ) метод forEach.

А вот мне кажется, что расширение прототипов встроенных объектов только вводит путаницу в код.

Я в курсе ;) А вообще - почему "не надо"?

Возможно, но, если пишется локальный фреймворк - почему нет? Если популярный фреймворк для общего использования и есть соответствующая документация - почему нет? Monkey patch - вполне удобная практика в динамических языках.

Ну тут сначала нужно разделить случаи. Первый -- это нивелирование различий браузеров: тот же forEach (да и остальные методы, кроме reduce-reduceRight) везде есть, в ИЕ нет. Второй случай -- добавление своих методов. Тут я тоже не вижу путаницы. Простой и полезный метод last, например,

var lastElem = getMyArray().last();

Где тут путаница?

Вот если бы вопрос стоял "Расширять ли прототипы во фреймворках?", тогда можно подумать, но в каждом случае отдельно, в зависимости от его целей и задач.

Kolyaj,
Я бы реализовал функцию last(), а не метод в прототипе. Чтобы у других программистов не возникало вопросов при просмотре, например, такого кода:

var myArray = ["some", "thing", "here"];
doSomething(myArray.last())

Тут может быть непрозрачно, откуда взялся этот ласт. Но пример утрирован, конечно.

Может я и не прав, но думаю, что нужно локализовать свой код так, чтоб он не трогал глобальную область видимости и прототипы встроенных объектов (что тоже, по сути, глобально).

Оттуда же, откуда взялась бы функция. Ты ведь знаешь стандартные методы Array? Знаешь, что там нет last? Значит он где-то в проекте реализован. Значит можно кликнуть колесиком и перейти к реализации ))) Мы ведь, надеюсь, не говорим о тех, кто не знает JavaScript? А если ты не знаешь JS, значит ты не можешь быть уверен, откуда взялась и функция last.

Вложенный вызов функций читается хуже цепочки методов.

Вот я и спрашиваю, какие еще могут возникнуть проблемы?:)

Почему, почему, почему? Ведь очевидно, что две библиотеки подключают только очень небрежные люди.

Ну тогда лично я не вижу проблем :)

Kolyaj, я, вроде бы, тоже. Но не хочется опираться только на собственную самоуверенность в таком достаточно фундаментальном вопросе:)

1) 2) 3) Наверное не "менять прототипы", а расширять прототипы. Удобное, компактное расширение - идея прототипов, это хорошо. Плохо, когда причиной расширения становится не реюз и компактность, а "типа-объектное-программирование-чтоб-было" - любую мелкую задачу через Object. Раздражает прежде всего контроль за именами.

Zeroglif, да, конечно, расширять, я неверно выразился.

насколько мелкую?

Что вы имеете ввиду?

В общем, как всегда на этом форуме, — получил кучу очевидных ответов и туманных общих замечаний, и ничего нового. Печально, господа.
Неужели мы тут только для того, чтобы высокомерно отвечать новичкам, которые не то что JS, русского языка-то не знают?

hogart, почему туманных? Здесь были и конкретные ответы/советы. Можно ещё раз:

Нет, не плохо, к тому же - заложено в идеологию языка. JS - динамический язык.

Подводные камни:

- конфликт имён (подключение нескольких библиотек, но здесь - не важно - в прототипе описано или нет - в двух фреймворках может быть и две глобальные переменные, как, например, $);
- в идеале, нужна документация для других программистов;
- расширять Object.prototype не следует;
- расширять Array.prototype можно, но тогда будет ограничение на итерацию по массивам через for ... in (либо, использовать в паре с .hasOwnProperty, либо "индексный" цикл (for var k = 0; k < .. ; k++), либо методы типа .forEach).

Что смущает?

Dmitry A. Soshnikov, ага, вот это уже лучше. Давайте обсудим.

Ок, согласен.
Но, например, Python — тоже динамический язык, и в нем точно так же можно дополнять/менять поведение встроенных типов, но там это считается дурным тоном — и есть типы, аналогичные встроенным, но предназначенные для наследования/переопределения.

в идеале она нужна (читай «должна быть») всегда (и это одна из тех очевидных вещей, о которых я говорил). В идеале, видя коммит без комментов, я должен пойти и дать по шапке за такое.

Не могу себе представить, зачем бы мне понадобилось итерировать по массивам через for..in.

Да ладно? В Питоне, в отличии от JS (или Ruby), нельзя расширять встроенные классы. Расширьте-ка, object. Или dict. Или ещё что. Наследоваться - это одно, а расширять - другое.

Я отметил в плане "подводных камней". Если будет метод массива [].last(), кто-нибудь (пришедший, например, из статических языков) может подумать, что это стандартный метод и потом использует в другом проекте, где никакого .last уже не будет. С другой стороны, если известны стандартные методы, можно сразу определить, что это - расширение.

Вы про Питон упомянули? Там Вы for ... in не пользовались? ;)

Да, это я не подумавши ляпнул, извините. Хорошо, возьмем не встроенные классы, а встроенные функции.
И опять таки — расширение встроенных классов запрещено на уровне языка. Хотя большинство питонистов все-таки более сознательны, чем люди, приходящие в JS.

какая-то очень эфемерная опасность. Нужно найти еще сишника, который не прочтет мануалы, перед тем как писать на неизвестном языке — а такие не выживают:)

А там есть for (i = 0; i < 10; i++)?

hogart,
Я, например, не вижу задач, которые бы рационально было решать с помощью расширения прототипов встроенных объектов. Ну, возможно, кроме маленьких вспомогательных методов, вроде last(), или методов для обеспечения кросс-браузерности.

Я бы не хотел встретиться в коде с такой конструкцией:

var a = [];
a.loadDOMNodes("div.someclass");

Даже если будет один фреймворк в проекте.

А что с ними "не так"? Их можно "расширить"?

Всего лишь - одна из реализаций. А в JS и Ruby - не запрещено, и что?

Нет, там нет такого цикла. Кстати сказать, если расширен Array.prototype, я использую индексный цикл или .forEach (нежели, естественно, for...in и .hasOwnProperty).

И ещё, в JS (с версии 1.7) достпен Array comprehensions (который позаимствован из Питона), и там используется синтаксис for / for each ... in:

var evens = [i for each (i in [1, 2, 3, 4]) if (i % 2 == 0)];

Андрей Параничев, мне кажется, вторая запись более наглядна, определяет сразу принадлежность метода, нежели первая, глобальная функция:

- removeFromArray(array, object);
- array.remove(object);

А если, ещё назовут не removeFromArray а просто remove - думай потом, к чему этот remove относится (но это уже, конечно, мифический случай)?

И все три способа в общем случае дадут разный результат.

Вот именно.

;)

Ну, Вы получили ответ на первоначальный вопрос? Картина прояснилась?

Dmitry A. Soshnikov, я так и не понял, зачем вы приводите параллель между питоновским for..in и JS-ным:)

Для примера (как подводный камень расширения Array.prototype). В целом же, никто не может утверждать, что for ... in нельзя / "не надо" использовать для массивов - это обычная конструкция, почему нет? А что, for ... in в Питоне и for ... in в JS - это такие мега-разные вещи, что между ними нельзя проводить параллель? К тому же, это не касается первоначального вопроса. Так с первоначальным-то вопросом разобрались (простите, что спрашиваю в очередной раз)?

достаточно разные, на мой взгляд.

Вы достаточно аргументированно и обширно высказали свое мнение, спасибо:)

Ну, "имхо" не возбраняется никогда ;)

А всё же, мне интересно, покажите, в чём?

в питоне for..in обходит список (или, скорее итератор:)). в JS for..in обходит словарь. Массив, конечно, можно назвать частным случаем словаря, но как-то не хочется.
И, чисто практическое соображение: массив в JS экономичнее обходится через старый добрый «сишный» for.:)

Python:

for (key, value) in {'a': 1, 'b': 2}.items():
    print(key, value) # a 1, b 2

for key in {'a': 1, 'b': 2}:
    print(key); # a, b

JS (1.7):

for (var [key, value] in {a: 1, b: 2}) {
    alert([key, value]); // a,1 ; b,2
}

for (var key in {a: 1, b: 2}) {
    alert(key); // a; b
}

for / for each ... in равно так же может обходить и массив, не только объект (см., опять же, array comprehensions).

var a = [1, 2];
for (var key in a) {
    alert([key, a[key]]); // 0,1; 1,2
}

Ага, т.к. не анализируется цепь прототипов, но это уже в сторону преимуществ, а не мега-отличий ;)

Давайте не будем про JS 1.7. Если вы имеете счастье на нем писать, то я рад за вас.

Давайте.

JS (1.5)

for (var key in {a: 1, b: 2}) {
    alert(key); // a; b
}

Python:

for key in {'a': 1, 'b': 2}:
    print(key); # a, b

Вы правильно трактуйте подачу, а не неадекватно ;) Расслабьтесь, это всего лишь форум.

В Питоне, for ... in итерирует и словари (равно, как и в JS объекты) и списки (равно, как и в JS - массивы). Сейчас картина прояснилась?

Что-то осталось недопонятым?

Не соглашусь. В приведенном вами коде хорошо видно, что итерация идет по списку, элементами которого являются ключи словаря:)

Мне непонятны две вещи.
* Почему я почти не слышу других мнений, кроме вашего;
* Зачем вы меня убеждаете итерировать массив for..in'ом?:)