Комментарии 33
Забавно выглядит.
Сам все через прототайпы наследую, тоже с головой подходит, сделал «умный» механизм «наследования» и его юзаю, но и так тоже можно делать. Этого метода кое где даже и плюсы есть.
Сам все через прототайпы наследую, тоже с головой подходит, сделал «умный» механизм «наследования» и его юзаю, но и так тоже можно делать. Этого метода кое где даже и плюсы есть.
Поясните, из каких глубоких соображений .name — в нижнем регистре, .THOUGHTS — в верхнем?
И вот это:
Вообще зачем?
И вот это:
Programmer.prototype =
{
constructor: Programmer,Вообще зачем?
Обычно в верхнем регистре именуются константы — в таком случае еще часто выношу в prototype, тут подумал что для примера пойдет, сейчас поправлю чтобы понятнее было :)
Да понятно, что так записаны константы.
Т.е. Вам понятно, что имя человека — НЕ константа, а мысли — константа???
А все равно, что означает в имя переменной. Если в верхнем регистре, то это константа и не может быть изменена, если в нижнем, то это переменная, а «папа» или «мама» все равно.
вообще-то да. Исходим из мысли, что все инстансы класса Men (sic!) думают одинаково, но у каждого разные имена.
Правда вот этот вот класс Men очень глаза режет вторую статью, при том, что после него идёт Gentleman.
Правда вот этот вот класс 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 — чисто информативное поле. если его не переопределить — все всеравно будет более или менее работать.
Лично мне удобнее задавать Prototype объектным литералом. в процессе этого правильное значение из поля constructor — теряется. и я его просто определяю заново.
prototype.constructor и instanceof насколько я знаю не связанны. constructor — чисто информативное поле. если его не переопределить — все всеравно будет более или менее работать.
Т.е. constructor следует восстанавливать для того, чтобы можно было создать новый объект того же типа в любом месте (так сказать из яблока путём генной инженерии и gps найти его мать-яблоню, чтобы нарвать ещё)? Признаюсь, ни разу не сталкивался со столько экзотичной ситуацией, где это бы пригодилось, но порядок есть порядок, и мне, пожалуй, стоит слегка подкорректировать пару своих велосипедов. Надеюсь, теперь я правильно понял вас? :)
Запустил, но так и не понял в чём подвох :) Я правильно понимаю суть? Я вижу её так: тело функции по умолчанию является её конструктором, который при желании можно изменить в её prototype. Если правильно, то я не вижу смысла в этих шаманствах, ведь мы не меняем constructor на какой-либо иной. В javascript-garden подобная строка прокоментирована как «Убедимся, что Bar является действующим конструктором».
правильно :) только когда таким образом переопределяем prototype мы всетаки меняем конструктор на какой-то иной — в поле конструктор там теперь Object();
по моему примеру firebag пишет вот что:
по моему примеру 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'ы, которые к ООП имеют отношения не больше, чем, скажем, то же АОП, и гораздо лучше бы иллюстрировались родными понятиями языка, без «наворота» реализованных классов.
Под ООП я понимаю классическую теорию, а не тенденцию к мультипарадигменности в современных языках.
Любопытная получилась связка: тут же в статье используется терминология ООП, которая в яваскрипте так или иначе реализуется на базе прототипов. И есть 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 стало вроде-бы все понятно…
Чтобы не объясняться, можно сказать «классовым», хотя тоже чуть криво, но уже лучше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Javascript примеси для чайников