2 Dmitry A. Soshnikov>
Просто, тогда получается, что производимые на основе такого прототипа потомки будут после каждого изменения прототипа разными, что в корне отлично от статического ООП , который при одних и тех же входных параметрах конструктора по операции new создает ничем не отличимые кроме адреса-ссылки экземпляры-клоны.
Мне казалось , что здесь тоже должна быть какая-то устойчивость прототипа, т.е. изменение его свойств в течение работы программы мне казалось , хоть язык и динамический, чем-то особенным , т.к. в противном случае скорее всего создаваемые программой на основе изменяемого прототипа экземпляры не должны обладать массовостью - "язык генерирует штучную продукцию" ...

Да, в этом основная суть (и даже "прототип vs. класс" не столь существенно, как "статика vs. динамика"). Метапрограммирование с возможностью модификации кода в рантайме с "мутирующими" объектами - позволяют создавать системы гибче, нежели при статической организации.

К примеру, в Ruby on Rails (web-фрейморк на Ruby) при создании модели таблицы БД, у объекта-модели появляются (наряду с основным методом .find()) в рантайме методы find_by_имя_колонки: например, find_by_name, find_by_surename и т.д. - динамически расширяется класс модели методами, чьи имена построены по именам колонок в таблице.

Все js-фреймворки, которые добавляют всякие методы в прототипы HTMLElement'a и т.д. (например $('#some-id').show() - и все инстансы HTMLElement "чудесным образом" имеют метод .show).

P.S.: динамическое изменение кода называется на жаргоне "Monkey Patch"

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

А внутри тел - всё тот же стандартный find с нужным фильтром. Делается это больше для абстракции и человекообразности кода.

Повышение абстракции. Методы (во всяком случае, в данной конкретной реализации - в ActiveRecord в Ruby on Rails) создаются "лениво", а не вся куча сразу для каждой колонки. При первом обращении к несуществующему методу (такие случаи отлавливаются специальным методом method_missing), он создаётся; дальнейшие вызовы уже не тратят на это время.

Это самое непонятное. А как эта самая абстракция может использоваться далее, т.е. что она нам дает ( про человекообразность уже даже и не спрашиваю ) ?

От чего же? Я вижу будущее программирования, как сведение написания кода вообще к минимуму и общение с машинами/роботами и т.д. на языках приближённых к человеческим. Но это отстранённая философия, конечно ;)

Упрощение, очеловечение.

Но. Основным моментом, всё-таки, является не просто "косметические украшения" типа "find_by_что_то_там", а - динамические изменения с целью определения нужного функционала (возможно, определяемого по ситуации, - с одними входными параметрами объект будет иметь одни свойства и методы, с другими - другие). Т.е. это расширение/сужение объектов, согласно "меняющейся ситуации".

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

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

Как правило, меняются не тела методов (хотя, никто этого не исключает), а объекты при мутировании обрастают новым функционалом. Написали Вы объект, рассказали о нём. Дальше десять других программистов написали плагины (Monkey Patch'и) к Вашему объекту - при подключении этих плагинов, объект приобретает/видоизменяет необходимый функционал.

Поэтому, здесь можно даже рассмотреть два вида динамического изменения объектов: (а) на этапе проектирования (когда подключаются плагины), (б) - в рантайме, по изменяющимся условиям (например, имена колонок таблиц).

Если сам объект-прототип не менялся (на другой), то объекты-экземпляры "видят" его одинаково, главное, чтобы вновь добавленное свойство существовало в момент обращения к нему.

Но практически это ничем не отличается от статического ООП программироания в Java. Там так же точно , например, один написал систему в которой определены интерфейсы (или абстрактные классы) общения с объектами этой системы , после чего другие пишут развитие этой системы , реализуя эти интерфейсы. Т.е. это все стадия проектирования, где осуществляется не динамическое , а статическое программирование. Отличие от java в этом случае будет только в гибкости - в javascript можно :
- добавлять новые методы, удалять старые ( причем, в отличие от java, уже реализованные ) ;
- добавленная программма плагина может переопределить методы уже созданных инстанций, если вызывается после их создания.
Но это все , как я вижу, не есть действительно динамические качества программы , которые должны были бы проявляться как изменение тел свойств объектов, построение новых конструкторов со своими методами программой, которая УЖЕ спроектирована , а ее гибкость.

А это действительно будет динамикой , т.е. уже существующая программа умеет создавать новые свойства своим объектам.Но опять же здесь, если я правильно смог понять, это не так целесообразно делать по сравнению со статическим ООП java, т.е. это скорее получается удобная гибкая особенность(фича) языка. Т.е. внешним модулям можно разговаривать с таким объектом свойства которого подстраиваются в зависимости от их требований так :

find_by_name,  find_by_surename ,  find_by_любимое _блюдо  ...

а статическая ООП программа тоже самое будет делать так :

find_by("name"),  find_by("surename"),  find_by("любимое _блюдо")  ...

Не очень в этом случае понятно в чем будет преимущество от динамичного(самостоятельн� �го развития программой своих объектов) кроме уже вышесказанного будут формироваться только слова общепонятного языка общения между компонентами системы . И даже еще программисту придется понимать этот дополнительный язык - вместо одного слова find_by с параметром появляются много слов .
Раз "как правило, меняются не тела методов (хотя, никто этого не исключает)", так если никто этого не исключает , то нельзя ли привести пример, когда действительно уже спроектированная программа строила новые конструкторы со своими методами , изменяла тела свойств объектов .

PS Поправьте меня, если я что не так понял и толковал .