Object.prototype.b

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

Добавлено через 2 минуты

0

Вообще-то, a.b -> undefined в твоем примере, потому что a не содержит b непосредственно, прототип а совпадает с Object.prototype, если Object был конструктором a; в свою очередь, Object.prototype также не содержит b непосредственно, а его прототип нулевой (null), поэтому возвратит undefined.

Обрати внимание на такой факт:
Object.[[prototype]]==Object.prototype и этот объект (в наивном смысле) не является экземпляром Object. Данный объект равен null. В этом смысле он порожден Null (хотя можно сказать, что это вообще необъектное значение, и хрен кто разберет там, где обёртки, где не объекты)
В цепи прототипов, подобно списочным конструкциям, маркер конца необходим, если же мы не хотим допустить возможность появления бесконечных списков.

Лирическое отступление: если список таков, что последующий элемент однозначно определяется предыдущим и набор различных элементов списка (т.е. множество А из опр. Хоара по ссылке выше) конечен, то бесконечность эквивалентна зацикленности. Вместе с тем, невозможна ситуация, когда на конечном наборе объектов с терминальным элементом (в нашем случае это null, эквивалент NIL из опр. Хоара, см. ссылку) реализуется бесконечный список. Эти два утверждения гарантируют, что используемая нами модель работоспособна в реальных условиях, если прототип Object (как первооснова всех объектов) есть null.

1

Mysterious Light, спасибо, но понял я не очень много Вот в чем сама проблема:
Этот код выдает функцию Object.
Хм.... Что-то начинает проясняться. Данный код:
выдает объект, функция c, значит, прототип смотрится не по конструктору. В смысле когда интерпритатор не находит свойства d в объекте a, то смотрит не в прототипе присвоенного конструктора a.constructor.prototype.d, а в настоящем конструкторе. Но все-таки не думаю, что это как-то связано

0

Hagrael, я в большинстве своих рассуждений опираюсь на http://javascript.ru/ecma, как на авторитетный источник, не имеющий разногласий с реальностью.

В предыдущем посте я опирался на http://javascript.ru/ecma/part15#a-15.2, однако, несколько неправильно трактовал то, что там написано. А именно (проверяю в FF):Первая строка как раз объясняет Ваш первый пример; вторая строка утверждает то, что я пытался объяснить постом выше.

Второй же Ваш код объясняется в принципе прототипного наследования в JS: http://javascript.ru/ecma/part13#a-13.2.2
Обрати внимание: прототип объекта ([[prototype]], в FF это эквивалент __proto__) устанавливается равным свойству prototype (кстати, свойство prototype может отличатся от прототипа [[prototype]]) конструктора. Изменение свойства constructor (кстати, полный путь к нему a.constructor, а не a.__proto__.constructor) не влечет за собой изменение прототипа a (ведь мы-то не меняем a.__proto__.constructor), поэтому по-прежнему a.__proto__ == b.prototype.

1

Mysterious Light, ну я понял, в общем, у прототипов своих прототипов не может быть А вообще мне надо бы спецификацию почитать и в правду.

0