Заработало, но вот вывод алерта меня удивил:
я ждал: 'name: preved\nparam: medved'
а получил: 'name:foo\nparam: preved,medved'

Почитайте документацию.

Да я уж понял, что второй аргумент это массив. Просто по примеру, это не очевидно.

Ещё раз: у объекта одна, единственная, цепь прототипов.

1. Расширением (что то же самое, что и реализация интерфейсов в Java).
2. с помощью __noSuchMethod__

Непосредственный предок и будет (тот, на кого будет указывать __proto__ и т.д. до Object.prototype). А дальше к этому __proto__ Вы подмешиваете методы из другого "модуля" - обычным расширением.

это все замечательно, а кто-нибудь знает примеры, когда множественное наследование удобнее обычного, желательно с указанием причин?

2 x-yuri> А чем Вас не устраивает моя причина - повторное использование кода ?

Тогда можно дальше множественного наследования смотреть. Вот старая статья (не знаю, чья, нашёл в у себя в закладках), может сойти за введение в code reuse.

я просто не сталкивался с ситуациями, когда оно удобнее обычного. Вот и спрашиваю про такие

2 x-yuri > Так а чем "эти ситуации" могут быть отличны от "обычных" ?
При обычном наследовании от от линейной неразветвляющейся цепи предка мы :
1) используем повторно код предка и его линейной цепи предков
2) используем их идеи и модифицируем их своими новыми

При множественном наследовании от неколькоих предков (генеалогическая цепь которых когда-то разветвилась от одного прапра...предка ) мы :
1) используем повторно код (Которого уже БОЛЬШЕ чем в первом случае, поэтому эффективнее повторное использование ) этих нескольких предков
2) используем их идеи (которых БОЛЬШЕ , чем в первом случае, поэтому мы становимся богаче идеями) и модифицируем их своими новыми .

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

слово удобнее очень даже подходит: я не знаю, зачем мне использовать множественное наследование пока что; я не сталкивался с ситуациями, когда "... как же это сделать :-? о-о множественное наследование, ты можешь меня спасти:victory:"

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

p.s. по поводу возможностей и по-больше есть статья Дейкстры Смиренный программист

2 x-yuri > просмотрел по диагонали Вашу ссылку - статья сорокалетней давности не имеющая отношения к теме . Что Вы вообще хотите ?

Это классика.

Может кто-ни ответить , для чего задумано свойство length у конструктора Object ?

По дефолту. Чтобы было. ;)

2 Zeroglif > Вы про 15.3.5 Properties of Function Instances
а я про объект Object , т.е. про Object.length

Object - это не функция? ;)

Мне 35 лет, 20 я занимаюсь программированием. Знаю много языков. OOP для меня родной дом. Стресоустойчив, много лет работал под давлением. Ни что мне не могло взорвать моск.
Сегодня с бодуна я решил почитать это. Поздравляю вы взорвали мне моск.

Вы имели в виду классовое ООП дом родной? Если 20 лет использовать только классовое ООП, то ни на какое другое лучше не переключаться, да :) Лучше вообще ни на что не переключаться.

Ну не мог я 20 лет использовать OOP ну не было тогда его еще толком :)
Да я давно уже переключился на руководство, но сам во все вникаю.
Страдаю убеждением что OOP позволяет экономить время разработки и делает код более понятным и модификабельным. Посему и смотрю на это активно. И всех кого могу тоже обращаю в эту религию.
Кстати те кто сейчас с десктопов в вэб не переключаться через 5-10 лет без работы останутся.

А моск вы мне взорвали потому что вместо упрощения ситуации с разъяснением произошло ее большее запутывание :)

Добавлю еще, на этот раз по теме.
Пересмотрев кучу информации по ООП в ЖС для себя заключил что реализация ajaxoop наиболее удачна.
Однако у них все напихано в одну библиотеку ... зачем то.
Уж наберусь сил, выдерну код от туда который касается классов.
По их утверждению там всего 30 строк требуется.

какое смелое пророчество...

у нас в офисе среди прикладных разработчиков тоже бытует такое мнение, но я не думаю, что С++/C# исчезнут, возможно интерес спадет, но не исчезнет

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

вэб тоже под угрозой. :( Все больше и больше на CMS делается. Причем мышкой, а не программируется. Будем вместе куда то переключаться.

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

ничего не нормально. Модуль создается и он существует. Уникальные модули под сайт(или кастомизация существующих) - очень даже можно обойтись - это не создание сайта. Бюджет другой. А большинство сайтов все таки типичные, и под них есть готовенькое или почти готовенькое. Я конкретно - друпалом занимаюсь, и вижу как это реально(а не теоретически) происходит. Больше 6000 модулей готово.

Я разве сказал что C++ будет не нужен?
Я сказал что десктопные приложения станут ненужными.
Ну если называть WEB облаком, тогда облако конечно.
Что касается "мышиного" создания приложений. Да этот сегмент будет расти. Мы наблюдали подобную эволюцию уже не раз.
Однако наблюдая пользователей я могу со 100% уверенностью сказать, что программисты будут нужны. И не важно мышкой он или в нотпаде программы пишет. Потому что программист в первую очередь, это тот кто понимает как оперировать данными. Почти 100% пользователей в эту тему не фтыкает и фтыкать не хочет (не может).

P.S.
CMS это тоже вэб, и что то делать там тоже надо понимать.

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

Excel то он и в африке Excel, только вот когда возникает Агрегация , тут и начинается проблема в понимании. А чем отличается фильтр от сортировки или что такое группировка. Все 99,5% прользователей отваливается. Основная цель фреймворков и всяких там CMS это концентрация разработчика на бизнес логике а не на тонкостях выделения памяти и представления строковых констант.

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

давайте остановимся на том, что тот, кто умеет программировать без работы не останется. Или я не прав? ;)

По сути да, а вот на практике может и подругому получиться.
Приятели мои организовали конторку и бодро фигачели на VB + Office.
Бизнес анализ планирование всякое. Продукт был очень хороший.
Грил я им, переползайте на 1с!
"Что бы мы да боги компьютерные на этом говне работали..."
отвечали мне они.
Настал кризис. Нет больше ентой конторки.

Читал статьи, из раздела ЧаВо этого форума. Но у меня возникли проблемы.... Не совсем понимаю, чем свойство объекта prototype отличается от свойства __proto__ реализованного в некоторых движках. Они ссылаются на один и тот же объект?

Нет, они обычно ссылаются на разные объекты.
У каждого объекта есть внутреннее свойство без имени (в спецификации его обозначают [[Prototype]], в некоторых браузерах оно доступно через __proto__, но это не имя его, а лишь способ доступа), которое обозначает его прототип. Во всех современных браузерах значение этого свойства доступно через Object.getPrototypeOf(obj). Цепочка прототипов объектов определяет путь, по которому у объекта при чтении или записи ищется свойство.
Свойство prototype - это обычное свойство с именем "prototype", которое могут иметь объекты. Все пользовательские функции обязательно имеют это свойство, объекты не являющимися функциями могут иметь его, а могут и не иметь. Это свойство особенно полезно, когда пользовательская функция вызывается как конструктор: у новосозданного объекта устанавливается прототип (безымянное свойство, о котором говорилось раннее) равным значению свойства prototype конструктора.
Прототипом любой функции является начальное значение Function.prototype. За исключением того, что начальное значение Function.prototype само является функцией.

oneguy
Спасибо за подробный ответ! Очень благодарен. Стал читать спецификацию ECMA-262 5.1 и некоторые моменты становятся яснее.

var object = {};
object.constructor.prototype = null;
alert(object.toString);

var object = {};
object.__proto__ = null;
alert(object.toString);

Подписался на тему, хоть еще не листал.

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

Хотелось бы проверить понимание примеров, приведенных monolithed.
Фактически и и указывают на один и тот же объект.

В первом случае делая так:
мы лишь затираем ссылку на объект, но он по прежнему доступен как object.__proto__ (object.[[Prototype]]).
Во втором случае

object.__proto__ = null;

получается потеряна не только ссылка но и т.к. у объекта (прототипа) больше не существует свойства constructor.
Раз на объект (прототип) больше не указывает не одной ссылки, он уничтожается сборщиком мусора.
Верно ли я понял? :blink:

Нет, неверно.
При выполнении object.constructor.prototype=null ничего не происходит, потому что object.constuctor равняется Object, а в нём свойство prototype имеет атрибут writable: false. В строгом режиме выдаётся ошибка.

"use strict";
var object = {};
object.constructor.prototype = null;

При выполнении object.__proto__ = null, у object прототип меняется с Object.prototype на null, при этом объект Object.prototype продолжает существовать, так как на него ещё ссылается много ссылок.

oneguy,
Ага, получается что строка object.__proto__ = null; просто разрывает связь текущего объекта object с его прототипом Object.prototype, правильно?
Тогда такой вопрос, раз Object.prototype продолжает существовать, его как-то можно уничтожить (не в смысле "зачем", просто любопытно)?