Насколько я знаю наследование в java-script-е реализуеться с помощью прототипов



Полсе работы этого скрипта будет 2 алерта

1. a1
2. a2

Так вот вопрос:

как из наследника вызвать метод предка, если предок переписал этот метод??

p.s.
например в java-е используем super
 

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

Второй концептуальный момент, в конструкторе создавая методы через this.method = function ты для каждого обьекта создаёшь новую функцию, т.е. этот метод не являеться чем то общим для всех a1. Closures конечно вещь эффективная, так что потерь производительности в принципе нет.

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

Собираем до кучи всё сказанное выше, соображаем: в JS "ООП" устроен несколько иначе, заменив прототип другим обьектом мы не наследуем, мы в прямом смысле (ну почти  ) говорим  "этот обьект эквивалентент другому", даже instanceof это докажет.

Ну и заключением всего поста будет код как можно провернуть таки наследование в стиле Java:


Медитируем. Совет: не стоит выделывать Java из JS, обратись к изяществу Ruby 
Помни что классы в Java это в первую очередь прямое отображение "физики" (размеры структур в памяти и т.д.), а т.к. Java с жёсткими типами в корне отличаеться от JS с duck-typing'ом, то приведение параллелей ни к чему хорошему не приведёт. Ruby чистый ООП скриптовый с "динамическими" типами язык. Вот так и стоит писать под JS. Примеры можно глянуть в prototype фреймворке.

Думаю сим длинным постом дал пищу для ума 

P.S. нашёл в prototype.js пару упущений и один серьёзный глюк, уже задумал prototyped.js на базе первого 
P.P.S однако заработался... прихожу на форум редко, пишу длиннющие посты... =)    

Спасибо за пост.

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

+---------+-------------------+-----------------+
|  тело   |       поля           |прототип      |
+---------+-------------------+-----------------+
| this      |                         | constructor   |
|             |     prototype-> |                      |
|             |                         |                      |
|             |                         |                      |
+---------+-------------------+-----------------+

Как и все обьекты она имеет поля. Вместе с тем она имеет еще тело которое начинает работать когда вызываем функцию, в теле имеются локальные переменные. Она также содержает внутренний обьект прототип.
В полях функции содержится предопределеное переменное-ссылка: prototype который показывает на прототип.
В прототипе содержится предопретеленное переменное constructor который ссылется на тело функции-обьекте, то-есть на функциональную часть.
Функция выполняет также роль класса, при помощи оператора new. При этом создается обьект в полях которого есть поля ссылки на поля прототипа. При создании обьекта вызывается код функции. В нем есть предопределенная локальная переменная ссылка this, которая ссылается уже на поля обьекта который создается.

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

Вопрос:

Насколько мое понимание соответствует действительности??

p.s.
опыты  сделанные мною не противоречат теории  
 

Любая функция являеться instance конструктора Function, который в свою очередь "наследует" от Object. Любая функция это обьект, в JS вообще всё это либо обьект, либо примитив. Примитив не имеет полей как обьект и не может сохранять новые поля, хотя при обращении с ним как с обьектом пользуеться прототипом встроенного wrapper'а (String, Boolean etc).

Откровенно говоря в JS функций нет   Есть замыкания, мы оборачиваем некий код который сохраняет свой контекст, затем этот код можно вызвать позже. Замыкая код несколько раз (функция в функции например) мы получаем несколько instances "функции", каждая из которых будет содержать свой контекст - ссылки на видимые переменные.


Поле constructor предопределено почти у всех обьектов (кроме DOM элементов в ИЕ, отстойничает зараза) (window, location и прочие "legacy" обьекты тоже без конструкторов) и указывает на конструктор обьекта. По конструктору можно добраться до прототипа. Прототип функции это, по дефолту, пустой обьект с полем constructor указывающем на функцию (порождён от функции, но без её запуска).


Не совсем, this указывает на любой обьект на котором вызвали функцию. Для примера:


JS гибкий язык, кто-то пользует его как декларативный, кто то структурно и C подобно, ещё чаще как чистый ООП. Найди свой подход     

Но замыкание все же делается при помощи instancе-ов конструктора Function 
То-есть  instancе-ы Function отличаются от instancе-ов других конструкторов "радикальнее"( грубо говоря )--они умеют оборачивать код 

Угу, как new String породит новый wrapper строки. Только фишка не в этом, а в том что closures обычно пользуют несколько шире чем функции, глянь сюда: http://forum.vingrad.ru/index.php?showtopi...st&p=715636  

a что эсли это поле просто ссылка на соответствующее поле прототипа, как ссылки на другие поля прототипа?? 

Оно себя так и ведёт. Одно всегда верно, пользовательский обьект не может не иметь конструктора и от этого конкструктора можно всегда создать новый обьект + работать с прототипом. 

не понимаю, что имеешь в виду, смотрю на топик и ничего необычного не вижу
 

Ну вот ещё пример: http://forum.vingrad.ru/index.php?showtopi...st&p=677242
Вообще вся тема интересна. 

То-есть используют код в "контексте" обьекта несколько шире чем в "контексте" функции? 

Перечитал фразу несколько раз... слишком широко охватывает понятия контекстов, и вообще чую "не туда идём" 

В JS closures ведут себя также как везде, где они реализованы, т.е. замыкаеться некий код в некую "функцию" + сохраняються все видимые ссылки на переменные. Именно ссылки, т.к. значения переменных могут потом измениться, это всё доступно и "видно" из замыкания. Теперь добавь сюда особенность ссылки this указывать на "нечто" на ком вызвали замыкание - получили обьекты с методами. Также добавь сюда особенность функций с оператором new, который создаёт пустой обьект, связывает поле constructor с функцией родителем и вызывает функцию на новом обьекте - получили конструкторы обьектов.

Это то что реально происходит. Дальше в эту модель можно внести наработанные приёмы типа приватных полей и методов обьектов. Это бывает удобно, хотя всегда "понарошку" т.к. процессы лежащие за приёмом создают только видимость + свои side effects. Это редко было проблемой, гораздо чаще встречаеться наоборот не использование выразительности JS, т.к. не сразу удаёться "врубиться" в приёмы (методология) декларативных языков.

Стоит увлечся этим: Ruby, Python и Groovy