Локальные переменные не важны. Это просто одна из возможностей.
А вот "обвешивать" объект мне не нравится - это точно.

Тут не соглашусь. instanceof работает как ему положено. Вопрос в том, правильно ли мы его используем. Понятно, что в javascript-е можно перехерачить любой объект до неузнаваемости, но в таком случае, его никто и не узнает :)
Если архитектура приложения правильная, то иерархия наследования не может быть не стабильной. Если цепочка где-то ломается - плохая архитектура.
Язык дает программисту полную свободу, но не стоит ей злоупотреблять.

Ну, вот и причина.

А как бы вы его (оператор) правильно использовали? Пусть мы узнали, что sidorov instanceof Person, и что дальше с этим делать?

если тебе помогает, это хорошо. Я просто не знаю, как оно мне может помочь :blink:

имелось в виду "Сделай так просто, как возможно, но не проще этого"

оно не может быть абсолютно естественным, т.к. это наследование, построенное на базе прототипного (естественного) наследования

что-то мне кажется, что не все так однозначно - "только классические иерархии, к которым мы привыкли в статических языках"

:confused: Даже не знаю, что и сказать... Да что нужно, то и делайте. Это же просто инструмент. Это тоже самое, что сказать "ну есть у меня молоток и что с ним делать?". Не знаете что делать, значит вам не нужен молоток :)

Зачем нам instanceof, если у нас duck typing?

Это уже какая-то философия.

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

Я просто хочу показать, что можно делать вот так, но не утверждаю, что по-другому нельзя.

Я знаю, что этот молоток мне совершенно не поможет, поэтому давно его не использую. Вообще. Просто вы сказали, что instanceof надо правильно использовать, что это определитель принадлежности объекта классу и проч., так как вы с ним работаете? На примере того же sidorov-а, допустим мы с помощью молотка instanceof узнали, что Person.prototype находится в где-то в цепи прототипов sidorov-a, и дальше что?

Под "правильно использовать" имелось ввиду с архитектурной точки зрения.
Загляните в код Prototype. Там есть примеры использования.

Ну вот, всё-таки, интерес больше академический, нежели прикладной (это тоже хорошо). Однако, в данном случае получается instanceof ради instanceof; на практике он вряд ли пригодиться.

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

А вообще, Что значит на базе? Это и есть прототипное наследование. Просто в удобной (в конкретном случае, для конкретного человека) обёртке. Суть там никак не меняется.

update:
а зачем подобный оператор в других языках (Python, Ruby) и при наличии duck typing'a?

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

:yes:

Я первый спросил.

А там не велика разница - если язык динамический ;) -

http://javascript.ru/forum/misc/2740...html#post12189

мне показалось, что Pavel_Volodko скорее хочет классовое наследование как в статических языках?

Не хотите говорить - не надо, только в либы не посылайте... ;)
У тебя словно переключатель в голове с надписью python, чуть потемнело - чик, "а вот в pythone так там вообще..." ;)

Zeroglif судя по всему там действительно вообще :blink:

Ну здрасте! Переключатель! :) Что теперь, если идеологии, действительно, похожи (но не идентичные, естественно), а терминология разная? Можно подумать, я на пустом месте это говорю.

наоборот - чуть найдена очередная схожесть конкретных технологий в общих "закономерностях"

P.S.>: да и... ты забыл Ruby еще ;) чик, "а там еще интересней Python'a и тоже - похоже на JS"

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

Q: Как использовать instanseof , если в текущий момент экземпляр уже на 100 км отличается от того, что использовался при его создании ?
A: Так же как и если бы он не отличался. Т.е., imho ,это вопрос вообще говоря о том, как вобще использовать instanceof в классическом ООП.

Можно определить, никто не мешает тому, как именно держать это в уме.

Ваш первоначальный конструктор может быть пустой безымянной функцией, которая связывает прототип с объектом и тихо помирает - ни имени, ни тела, ничего. То, что это первоначальный создатель видно по коду, но обычными словами род/тип объекта не выразить, признаков нет, уцепиться не за что. Суть объекта (что он наследует) возможно будет выражена где-то выше, допустим в цепи его прототипов есть Func.prototype, и этот конструктор Func вполне себе попадает в instanceof, хотя конструктором вышеуказанного объекта не является ни разу.

[code=Zeroglif]Можно определить, никто не мешает тому, как именно держать это в уме.[/code]
Так я же попытался не в уме , а на бумаге это определить.
Ввиду слабости в javascript я как-то не могу себе представить, как это возможно анонимный конструктор и его прототип сделать потомками еще какой бы то ни было пары Конструктор-прототип, т.е. я имею ввиду направить свойство __proto__ прототипа сопровождающего анонимный конструктор на другой прототип , ведь прототип , сопровождающий анонимный конструтор это Function.prototype :
Имеются тождества :
{n:"132" }.constructor===Object ;
{}.constructor===Object ;
function(){}.constructor===Function ;
Т.е. не будет в цепи наследования анонимных конструкторов .
Докажите, плз, если, где я ошибаюсь.
Впрочем, есть и такой вариант :
var s=new function(){this.n="132" ; } ; s.constructor!==Function
Но все равно и здесь не направить, свойство __proto__ на предка.

Вот. Но это одно.
А второе - если основывать приложения на простом правиле - не делать в цепи наследования анонимных конструкторов, то вопрос снимается .

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

ну это все детали, на самом деле
меня вот, например, интересует, зачем использовать классическое наследование в js. Пока я вижу одну причину: так привычнее людям, пришедшим с других языков

2 x-yuri > Мне кажется не в привычках дело, а в моделях (паттернах) и соответствено подходах к их построению , В классическом ООП создано много полезных моделей, не использовать которые было бы странно . Вообще До объектного подхода языками программирования не предлагалось никаких прикладных моделей . Модель - это главное слово в программировании. Поэтому не стесняюсь повторить его столько раз.
Конечно все imho, но как-то не вижу аргументов против.

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

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

2 x-yuri >
Я так понимаю - модель есть фундаментальное сильное красивое слово, которым можно обозначить все, что угодно, важно только понимать его смысл(отражение (и реализация этого отражения) некого предмета(предметной области) для достижения поставленной цели). Паттерн, разумеется, тоже модель, причем для своей реализации использующий как раз подходы ООП.
Т.е., паттерны (шаблоны), по-моему ( если ошибаюсь, докажите ) находятся как раз на уровне , привязаном к OOП. Просто я не встречал шаблонов для прототипного программирования (ПП), если Вы встречали - укажите где.
Из вышесказанного следует также отношение к вопросу - нужно ли использовать обертки для эмулирования классов:
классовые обертки позволяют сделать язык (т.е. инструмент) создания моделей более ясным (и значит, эффективным), что для реальных (т.е сложных) задач единственно возможный путь достуижения адекватного результата . Хотя опять же , что поднимать под обертками - я , например, пока предпочел бы пользоваться парой функций extend и mixing из http://javascript.ru/tutorial/object...nktsiia-extend а создаваемые с помощью их классы (Конструктор + наполнение его прототипа методами) оформлять текстуально в примечаниях (// Класс A ...<Здесь его конструктор A и наполнение его прототипа A.prototype > // Конец класса A) , что по моему как раз будет соответсвующим той гибкости, ради которой и задумывалось ПП.

Это нельзя назвать шаблоном для ПП?

2 Zeroglif > Можно, Но что с этого ? Это шаблон для эмуляции классового наследования (или, если хотите, классов ),т.е. это низкоуровневый шаблон. А шаблоны, о которых я вел речь выше, есть шаблоны построения из классов прикладных моделей . Есть такие для ПП ? Я не настаиваю, может и есть, я просто спрашииваю.

kefi, они просто есть, вне зависимости от ООП это или ПП. Возможно в обоих парадигмах есть специализированые. Но есть общие более высокого уровня (и таких, думаю, большинство). Поправьте, если ошибаюсь. Есть какие-нибудь примеры шаблонов, которые нельзя реализовать с помощью ПП?

2 x-yuri > Мне кажется, что патерны получили свое происхождение от ООП, и модели, которые они предлагают в проектировании оперируют понятиями класса , для прототипа же имеется отдельный шаблон, его использование во взаимосвязи с остальными еще нужно поизучать ...
Вот почитайте , http://ru.wikipedia.org/wiki/Шаблоны_проектирования .
Есть ли примеры, которые нельзя реализовать с помощью ПП, не знаю, но думаю, что есть, которые будут встречать большие трудности , чем их ООП реализации.

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

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