Ага.

Почему это? С интерфейсами пример не совсем схожий. В динамическом языке Вы подключаете плагин и он расширяет существующие объекты.

И даже на этапе проектирования - это уже динамика, которой нет ни в Java, ни в Cи, ни в любом статическом языке. Вы дописываете свойства/методы в существующие объекты/классы/прототипы - разве это то же самое, как в Java?

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

Подключение плагина - это этап проектирования, на котором программист ( а не программма, которой на этом этапе еще не существует ) может делать все, что угодно и в java (статическое ООП) . Поэтому это само по себе не является подходящим примером.

Не следует говорить о какой-то динамике на стадии проектирования , на которой программист может придумать на любом языке все, что угодно. Уже готовая программа должна уметь САМА изменять свои Классы.
Я не спорю, что в java не добавить методы, но реализовать, что то же , что и "изменить", абстрактные - это сплошь и рядом. Т.е. с практической точки зрения отличия мало. Кроме того классическое наследование позволяет использовать Полиморфизм, что тоже есть изменение методов, но это все заложено статически готовой программой, за исключением ДОБАВЛЕНИЯ метода, но тут вот Вы не показываете - где существенное отличие , т.к. пока я вижу только создание новых слов для общения практически с тем же телом метода ("внутри тел - всё тот же стандартный find с нужным фильтром")

Или еще вот так поясню свое понимание :
Динамика / статика должно пониматься по отношению к структуре Классов, заложенной созданной и более не изменяемой программы. Если в течении жизни такой программы в зависимости от внешних условий эта структура Классов меняется (от одной статики к другой статике ), то это будет динамичной структурой. Если же при уже заложенной, но неизменной стуктуре наблюдаем проявления ее гибкости по отношению к внешним условиям , то это имено гибкость этой структуры, но не ее измение.
Критерии отличия : возможность добавления(удаления, изменения) новых членов уже существующим классам, возможность добавления новых классов (удаления старых) во время жизни неизменяемого кода программы .
Вы показали пример с возможностью добавления новых членов, но как : просто добавлялись имена методов для обращения к тому же телу. Я не спорю, что это динамика, но практически это малоэффектный пример для действительной демонстрации динамики Классовой структуры, который имеет аналоги и в ООП программе со статичной структурой Классов.

kefi, стоп. Мне не совсем ясен посыл информации. У Вас цель какая? Понять, что такое JavaScript (и в целом, динамические языки)? Понять, чем отличаются динамические языки от статических? Найти/доказать сходство с Java? Или, может, ещё что-то? Какова цель? Так можно будет локализовать неясности.

Ещё раз. Суть динамики - в возможности изменения объектов. Вот есть мой объект A, у него есть 10 методов. Я подключаю Ваш плагин (и всё, больше я ничего не делаю, относительно Вашего кода, не реализовываю никакие интерфейсы, и Вы не реализовываете - я только подключаю Ваш плагин) - и мой объект А имеет ещё 20 методов + 5 моих изменённых. Где Вы в статике такое же увидели?

Ещё как следует. Стадия проектирования может содержать расширение (именно это динамика) уже существующих объектов/классов/прототипов (например, расширение стандартных объектов, типа Array, Number и т.д.). Где Вы в статике такое же увидели?

obj.method = (function () {
  if (IE) {
    return function _ie() {};
  }
  return function _other() {};
})();

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

update:

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

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

update2:

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

"подключаю Ваш плагин" - это и есть реализация , которая в java ООП делается на стадии проектирования .

Почти так, только не только сходство но и различие причем языков, а не технологий.
Вы практически когда говорите о стадии проектирования говорите о технологии. Ваш пример имеет неверный вывод Это этап проектирования, где программа определяет, какое тело будет у метода .method. . Программист тут определяет, а не программа!
Поймите, ведь если так смешивать стадии разработки и понимание динамики изменения Классов , определяемой самим языком, то можно любой язык назвать динамическим - ведь можно же в любом языке статического ООП в программе извне получить новые текстовые описания сигнатур методов или даже тексты самих Классов с телами Конструкторов и Методов, вызвать в run-time их компиляцию, получить готовые исполняемые коды Классов и использовать дальше их в этой же программе, передав им управление. Но НЕ БУДЕТ это динамическим созданием Классов.

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

Приведите пример. К примеру, есть класс Array. Приведите пример его расширения таким образом, чтобы все массивы имели бы метод .newMethod().

Да что Вы?

Приведите пример, что такое в Вашем понимании "определяет программа"?

Вот, пожалуйста, прочтите ещё раз предыдущие посты, и, всё-таки, постарайтесь понять, в чём заключается динамика. Напомню: динамика - возможность изменения структуры объектов после их создания.

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

О, нет, у меня нет с Вами никаких разногласий, я лишь стараюсь объяснить.

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

Больше подойдёт, "это всего лишь идеология технологии" - возможность изменять структуру объектов на протяжении их жизненного цикла.

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

Угу, Monkey Patching - расширение нужных, уже существующих, объектов.

Уже готовый Класс Array,не имеющий абстрактной сигнатуры newMethod(), как я уже говорил, не расширить новым методом, но если в нем заложен абстрактный метод, то реализовать тело в классе-Наследнике перекрыв эту сигнатуру - стандартная возможность java.

Вот пока сам я не готов и пытался это добиться от Вас. Это и была моя цель, но пока я не удовлетворен, т.к. Вы в своих примерах не хотите отличать язык от .

Вот на вскидку, должно быть что-то следующее :
Суть в том, чтобы имея неизменную программу, изменять структуру классов и чтобы программа, сама по себе оставаясь неизменной, могла понимать изменяющуюся в зависимости от внешних условий структуру обрабатываемых данных, Видимо, тела новых методов должны уметь "складываться" из каких-то алгоритмов-примитивов с помощью какого-то, повторяю, неизменного алгоритма рождения тела метода, Задача для для меня не простая, я думаю, javascript это может, и в этом плане есть какие-ни примеры реализации, что я изначально и пытался у Вас выведать, почему меня и не удовлетворило в Вашем примере просто создание новых имен методов без создания новых тел.

ПоследнийОбъектПрограммы=0;
for (var НомерОбъекта = 0; НомерОбъекта <= ПоследнийОбъектПрограммы; НомерОбъекта++) {

ПоследнийОбъектПрограммы=ПоследнийОбъектПрограммы+1 ;

Конструктор=НовыйКонструктор_Создаваемый_По_единому_неизменному_алгоритму_из_Примитивов_В_Зависимости_от_Внешних_условий() ;

Конструктор.prototype=НовыйПрототип_Создаваемый_По_единому_неизменному_алгоритму_из_Примитивов_В_Зависимости_от_Внешних_условий() ;

var o=Конструктор.рождает_объект // или var o=new Конструктор() ;
// объект o Проживает свою жизнь :
for (var НомерДня = 0; НомерДня < o.ПоследнийДень; НомерДня++) {
 o.ПланНаДень(НомерДня) ; 
};
o.умирает ;

} ;

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

В смысле?

Смените потребительский подход, пожалуйста, здесь Вам не справочная, чтобы удовлетворять по требованиям ;) Если хотите понимать, старайтесь понимать. Я ж не играю с Вами в игру, "кто интересней придумает, что-то образно-абстрактное", я просто - говорю, как есть на самом деле (имею в виду динамику объектов).

Ну, вот, пока придётся разграничить два понятия - Ваше понимание как "должно быть", и как есть на самом деле (пока они не совпадают).

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

update:

Вот это почему Вы решили?

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

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

Хорошо, давайте упростим вопрос, сделав его конкретнее : если я правильно Вас понял, в javascript, если не рассматривать подключение плагинов, тела методов и тем более тела Конструкторов новые не создают, а используют уже имеющиеся ?
И еще дополнение: под динамикой существующей программы понимается изменение ее существующих объектов путем заплаток(Перекрытий,Введен ием новых) их свойств , наставляемых им плагинами ?

Ну, и ладно тогда ;)

Я делюсь информацией, Вы попросили.

Нет, конечно (не знаю, каким боком я (?) привёл Вас к такому выводу).

function A() {} // конструктор со своим телом
A.method = function () {}; // метод (может быть тоже конструктор) со своим телом

Под динамикой объектов. Да. Только "плагины" здесь, всего лишь, как пример. Какой при этом термин выбирать: "заплатки", ещё что-то - Вы уже сами определяете, но, как правило, это расширение существующих объектов нужными свойствами/методами.

Например, популярный итератор в Ruby:

5.times do
  # что-то
end

В JS можно реализовать, расширив уже существующий (это динамика объектов - перечитайте эту строку несколько раз) объект Number:

Number.prototype.times = function (callback) {
  for (var k = 0; k < this; k++) {
    callback(k);
  }
};

И вызывать в программе:

(5).times(function (index) {
  alert(index);
});

Где Вы создаете тело? Создание тела, например, вот :
var A=new Function("a", "b", "this."+ТоЧтоВышеВвелПользова тель+"; return a + b" );

Зачем, если я сам об этом несколько раз писал? Я ж не спорю с этим.

И там, и там - "тело". Если это сложно осознать, могу лишь предложить дальше читать о JS, в частности, стандарт.

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

var A = function (a, b) {
  this['ТоЧтоВышеВвелПользователь']; // если, конечно, у Вас есть такое свойство/метод
  return a + b;
};

Сути это не меняет, в обоих случаях - динамические функции (FE), создаваемые в рантайме (только в случае с new Function еще и [[scope]] будет только глобальный).

'Function' парсит/eval-ит аргумент, создавая тело и проч., если именно эта eval-ная динамика подразумевается (новый агрумент -> новое тело -> новая функция), то в этом смысле обычная прописанная FE - вариант статичный.

Zeroglif, ну да (хотя, тело можно и проeval-ить).

Возник вопрос :
Интересно, в Javascript реализуется корректно множественное наследование ? Где-то можно увидеть описание, желательно понятным языком ?

А оно как-то реализуется, чтобы спрашивать про корректность ? ;)

Хороший ответ. Я сам-то вначале задал вопрос, а потом подумал о таком возможном ответе. Я могу сказать, что - не знаю. Но :
1) Хотел бы узнать, как это сделано в C++, поскольку тоже не знаю, как там, но термин оттуда слышал.
2) Хотелось бы услышать , как кто себе это представляет .

Если говорить о SELF-e, откуда JS зачерпнул свои прототипы, то там: "SELF’s inheritance system supports multiple inheritance by allowing an object to have more than one parent." В JS один или "more than one"? Один.

"Примеси" (обычным расширением). Но физически это, всё-же, расширение, а не ссылки на объект-"примесь" (как, например, в Ruby). Примеси позиционируются как альтернатива множественному наследованию.

В Java, альтернатива - интерфейсы, реализация которых, - есть полное описание (имплементация) методов этих интерфейсов; в JS того же можно добиться обычным написанием этих методов (или "подмешиванием").

update:

Если "js-кроссдвижковость" не столь важна (а именно - код пишется под Mozilla'вцев, Spider Monkey), то можно подключить механизм с __noSuchMethod__, в котором устроить нужную диспетчеризацию по дополнительным родителям (в __noSuchMethod__ управление передастся, когда вся цепь прототипов будет просмотрена, и нужный метод не будет найден).

2 Zeroglif >
А как там ( self ) решена проблема неоднозначности, когда несколько предков имеют метод с одинаковой сигнатурой и экземпляру потомка нужно вызвать метод с такой сигнатурой ?
2 Dmitry A. Soshnikov>
аналогичный вопрос с проблемой неоднозначности в мозилле как можно решить ?
Кстати, а цепь прототипов какого предка просматривать первой, какого второй и т.д. ?

kefi,

тынц

2 Zeroglif > Ну насколько я смог оттуда понять, SELF используют симбиоз упорядоченного и неупорядоченного множественого наследования, разбивая предков на группы по приоритетам, внутри группы разрешение имен - неупорядоченное, между группами - предпочтение отдается имени предка из более приоритетного уровня .
Причем, не знаю , верно ли я понял , неупорядоченное (это то ,что в C++) приводит к run-time ошибке при обращении к двусмысленным именам слотов ( т.е. именам имеющимся у нескольких родителей), т.е. получается проблема эта в C++ не решается, точнее компилятор заставляет програмиста обходить ее.

А какая неоднозначность, если множественного наследования нет? С Мозиллой лишь приводил одну из имитаций.

У объекта одна цепь прототипов. А в __noSuchMethod__ Вы уже сами определяете к каким объектам делегировать за нужным (не найденным в цепи) методом.

Но, мне кажется, для таких целей больше подойдёт обычное расширение - суть - та же имплементация интерфейсов из Java.

по поводу статика vs динамика, думаю статика лучше для статичного кода (который не будет сильно изменяться, например, библиотеки), а динамика для динамичного (например, пользовательский интерейс). Т.е. динамика облегчает изменение кода
по поводу множественного наследования (как в C++): первый вопрос, который стоит задать - зачем оно нужно? По-моему в основном для каких-то хаков библиотек, что можно обычно сделать за счет динамики языка (мне кто-то вроде приводил пример)
кроме того, вспомнилась фраза про множественное наследование в Perl, но решил также оставить описание проблем:

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

Но тем не менее она решается так или иначе. У природы тоже не всегда получается межвидовое(или, как там правильно,- межсемействами) скрещивание, какие-то получившиеся виды (Лошадь+Осел -> Мул ) дают вполне рабочий вариант , который правда далее не скрещивается ни с кем , Но в одном-то поколении его можно использовать.
И проблемы действительно можно доверять программисту

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

как и C++.

а можно реальный пример множественного наследования, когда оно нужно?

Из PrototypeJs:

Не множественное, но думаю продолжить не проблема:
Enumerable > Hash
Enumerable > ObjectRange

А вот здесь множественное:
Ajax.Base > Ajax.Request > Ajax.Updater
PeriodicalExecuter > Abstract.TimedObserver > Form.Element.Observer
PeriodicalExecuter > Abstract.TimedObserver > Form.Observer

Riim,
а множественное наследование где?

К тому же все (ну или почти) наследует от Object, так что цепочки Enumerable > Hash и Enumerable > ObjectRange можно переписать как:
Object > Enumerable > Hash
Object > Enumerable > ObjectRange

это цепочки наследования из PrototypeJs

Я подумал, что вы про многоуровневое наследование (не с начала читал). А примеры где может понадобиться наследование от нескольких классов придумать еще легче.

А разве в js это (множественное наследование) реализуемо?
Думаю вряд ли, ведь __proto__ только один.

Нет, но можно эмулировать (интерес только академический, приводил, как пример имитаций).

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

Хотел бы уточнить - Вы там имели ввиду , кто будет предком созданного т.о. Классного прототипа - один из родителей или Object.prototype ?
И Как Вы предполагали собирать свойства нового Классного прототипа или же все свойства у новог Класса предполагается иметь собственные (this-свойства) ?
( Класс=Конструктор+прототти п )

__proto__ это ссылка на объект. Только на один объект, у которого в свою очередь также только один __proto__, т. е. получается цепочка БЕЗ разветвлений. Но если вам удастся, как-то организовать это разветвление....

Не понял предложение. У объекта есть конструктор и прототип (в конце цепи будет Object.prototype).

Вы про какую реализацию спрашиваете? Если обычное расширение (свои this-свойства в прототип конструктора), то чем это принципиально отличается от реализации интерфейсов в Java?

Если Вы про __noSuchMethod__, повторю, в этот метод управление передастся, когда цепь прототипов объекта (единственная цепь) будет просмотрена и нужное свойство не будет найдено. Далее, в этом методе Вы уже сами определяете к каким "модулям"/"классам"/объектам (и их цепям прототипов) делегировать.

Первое, что придумалось не захотело работать:

var F = function() {};
F.__noSuchMethod__ = function() {
	alert('7');
	return 5;
};
var x = new F();
	
//alert(x.dfgdfd());
alert(x.dfgdfd);

FireFox и __proto__ есть.
Может сделаете простенький примерчик.

Несколько __proto__ показывают на один прототип - вот и разветвление.

Ну мы говорим о том как сделать Новый Класс из нескольких имеющихся.
Вот я и спрашиваю, что Вы предполагали в той ссылке - Кто будет непосредственным Предком Нового Класса, под Классом я понимаю = Конструктор+прототип. Т.е. на кого будет показывать свойство __proto__ прототипа от нового Класса ?

Смотря в каком направлении идти по этой цепочке. Думаю, что такое разветвление здесь не поможет.