Как стать автором
Обновить

Комментарии 33

Забавно выглядит.
Сам все через прототайпы наследую, тоже с головой подходит, сделал «умный» механизм «наследования» и его юзаю, но и так тоже можно делать. Этого метода кое где даже и плюсы есть.
Поясните, из каких глубоких соображений .name — в нижнем регистре, .THOUGHTS — в верхнем?
И вот это:
Programmer.prototype =
{
    constructor: Programmer,

Вообще зачем?
Обычно в верхнем регистре именуются константы — в таком случае еще часто выношу в prototype, тут подумал что для примера пойдет, сейчас поправлю чтобы понятнее было :)
Да понятно, что так записаны константы.
Т.е. Вам понятно, что имя человека — НЕ константа, а мысли — константа???
А все равно, что означает в имя переменной. Если в верхнем регистре, то это константа и не может быть изменена, если в нижнем, то это переменная, а «папа» или «мама» все равно.
вообще-то да. Исходим из мысли, что все инстансы класса Men (sic!) думают одинаково, но у каждого разные имена.

Правда вот этот вот класс Men очень глаза режет вторую статью, при том, что после него идёт Gentleman.
Спасибо огромное :) Поправил в обоих статьях.
Так может быть описана константа.
При такой записи переопределяется весь прототип, так что приходится определять его заново.
да все верно, спасибо что за меня оветили :)
«его» это в смысле конструктор. В Сибири вечер во всю… :)
Пардон, я так и не понял =(
var A = function(){};
A.prototype = {b:2};
var a = new A();
console.log( a instanceof A, a.b ); // true 2

Зачем?
попробуйте вот это запустить:
    var A = function(){ this._field = "test" };
    var a = new A();
    console.log( a.constructor.toString() );
    
    A.prototype = {}
    var b = new A();
    console.log( a.constructor.toString() );
ой, во втором выводе в консоль должно быть b.constructor.toString()
Кажется, понял. Проблема в этом?
var A = function(){};
var a = new A();
console.log( a instanceof A ); // true;
A.prototype = {}
new A();
console.log( a instanceof A ); // false;
Хотя, если заменить на A.prototype = { constructor: A }, ситуация с instanceof не исправляется. В общем ещё больше запутался :(
с instanceof вообще ситуация немного мутная — там скрытые поля, и как только нарушается цепочка прототипов — все пиши пропало instanceof не работает. я если честно незнаю как этому помочь, но поле constuctor тут вроде не помогает.
Вот вот. В итоге мы имеем: смена prototype полностью «сносит крышу» функции, и она заменяется чем-то иным. Однако, несмотря на смену конструктора, при создании нового экземпляра(путём применения к функции операнда new), наш старый(оригинальный) конструктор всё же вызывается, хоть и из недр [native code]. instanceof мы таким трюком не восстановили. В итоге вопрос на повестке дня — так что же даёт насильственное указание конструктора, кроме как избавление от [native code]? // javascript такой javascript :)
я наверное не очень удачно объяснил. Попробую еще раз: constructor — это стандартное поле в котором хранится указатель на функцию-конструктор. Зачем оно там лежит — это неважно. я могу ожидать что в этом поле всегда будет указатель на функцию-конструктор.

Лично мне удобнее задавать Prototype объектным литералом. в процессе этого правильное значение из поля constructor — теряется. и я его просто определяю заново.

prototype.constructor и instanceof насколько я знаю не связанны. constructor — чисто информативное поле. если его не переопределить — все всеравно будет более или менее работать.
Т.е. constructor следует восстанавливать для того, чтобы можно было создать новый объект того же типа в любом месте (так сказать из яблока путём генной инженерии и gps найти его мать-яблоню, чтобы нарвать ещё)? Признаюсь, ни разу не сталкивался со столько экзотичной ситуацией, где это бы пригодилось, но порядок есть порядок, и мне, пожалуй, стоит слегка подкорректировать пару своих велосипедов. Надеюсь, теперь я правильно понял вас? :)
дааа всё точно :)
Запустил, но так и не понял в чём подвох :) Я правильно понимаю суть? Я вижу её так: тело функции по умолчанию является её конструктором, который при желании можно изменить в её prototype. Если правильно, то я не вижу смысла в этих шаманствах, ведь мы не меняем constructor на какой-либо иной. В javascript-garden подобная строка прокоментирована как «Убедимся, что Bar является действующим конструктором».

правильно :) только когда таким образом переопределяем prototype мы всетаки меняем конструктор на какой-то иной — в поле конструктор там теперь Object();
по моему примеру firebag пишет вот что:
Sample2.js (line 12): function () { this._field = "test"; }
Sample2.js (line 16): function Object() { [native code] }
Константы поправил, теперь может будет немного понятнее
А какое отношение примеси имеют к ООП? На мой взгляд использование примера с «классом» здесь не уместен.
Примеси гораздо проще рассматривать именно в терминах прототипной объектной модели (примесь — объект-контейнер для функций-делегатов).
Иначе какая-то получается «идеологическая каша».
Вроде бы же так и рассмотрел:

var Mixin_Babbler =  
{
    say: function () 
    { 
        console.log("My name is " + this.name + " and i think:'" + this.THOUGHTS + "'");
    },
    argue: function() { console.log("You're totally wrong"); }
};

Как раз и есть объект контейнер, а функции добавляются в прототипы использующих примесь объектов.
Или я вас неправильно понял?
Нет, все верно. Просто поясню свою мысль, если позволите.

Любопытная получилась связка: тут же в статье используется терминология ООП, которая в яваскрипте так или иначе реализуется на базе прототипов. И есть mixin'ы, которые к ООП имеют отношения не больше, чем, скажем, то же АОП, и гораздо лучше бы иллюстрировались родными понятиями языка, без «наворота» реализованных классов.
Под ООП я понимаю классическую теорию, а не тенденцию к мультипарадигменности в современных языках.
А какое отношение примеси имеют к ООП?

У вас очень ограниченное Джавой понимание ООП.
если возникнет потребность использовать АОП на примесях, нужно будет еще немножко заморочиться — примешивать не сами методы примеси, а замыкания, вызывающие их:

вместо
object.prototype[prop] = mixins[i][prop];


писать

bindMethod = function(mixin, prop) {
    return function(){mixin[prop].apply(this, arguments)}
}

object.prototype[prop] = bindMethod(mixins[i], prop);


тогда можно и после примешивания миксина менять его методы:

var oldFoo = mixin.Foo;

mixin.Foo = function(){
    console.log('doing Foo!');
    oldFoo.apply(this, arguments);
}

Спасибо огромное. добавил этот метод в статью :)
После того, как с классическим (от слова класс) наследованием в JS стало вроде-бы все понятно…

Чтобы не объясняться, можно сказать «классовым», хотя тоже чуть криво, но уже лучше.
В англйикой литературе классовое наследование тоже обычно называют classical. Если честно мне такая игра слов кажется вполне уместной.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации