Комментарии 22
Я бы сказал, что уже скоро будет ES6 и все новые фичи ES5 уже не новые.
0
Интересно было бы запустить опрос, какая доля разработчиков использует фичи ES5 в повседневных разработках. У меня такой мысли не было, потому что думаю, что весьма небольшая. Но добавил опрос для проверки этого мнения.
0
В принципе ES5 поддерживается уже достаточно хорошо, и его уже можно использовать если забыть про всякие не важные мелочи и strict mode: kangax.github.io/es5-compat-table/
К сожалению ES6 будет доступен ещё не скоро.
К сожалению ES6 будет доступен ещё не скоро.
0
Мне кажется, что тут забыли Object.create
0
Хм, я использую
obj.constructor.prototype
вместо Object.getPrototypeOf(obj)
. Это плохо?0
В вашем подходе все в порядке. Если интересны подробности, то посмотрите вот тут — tobyho.com/2010/11/22/javascript-constructors-and/
+1
Потому, что может быть
obj.constructor.prototype != Object.getPrototypeOf(obj)
+1
Главное на грабли не наступать:
function F1(){};
F1.prototype = {
prop1: 1,
prop2: 2
}
obj1 = new F1;
console.log(Object.getPrototypeOf(obj1) == F1.prototype); // true
console.log(obj1.constructor.prototype == F1.prototype); // false - O_o
console.log(obj1.constructor.prototype == Object.prototype); // true
function F2(){}
function F3(){}
F3.prototype = new F2;
obj2 = new F3;
console.log(Object.getPrototypeOf(obj2) == F3.prototype); // true
console.log(obj2.constructor.prototype == F3.prototype); // false - O_o
console.log(obj2.constructor.prototype == F2.prototype); // true
+1
Как раз недавно запилил либу для множественного наследования: javascript.ru/forum/project/40210-jin-i-snova-o-nasledovanii.html
Множественное наследование — это безусловно классно, но есть ряд проблем:
1. Конфликты имён. Не должны методы одной примеси молча затирать методы другой. В моей либе вместо затирания происходит создания метода-конфликта. Чтобы разрешить конфликт нужно примешать такой метод в описании которого указано, что он пригоден для разрешения конфликта между теми конфликтующими методами.
2. Не всегда понятно какой метод/свойство взяты из какой примеси/класса. В моей либе каждый метод имеет глобальный идентификатор. А также есть функция которая раздаст идентификаторы уже готовой структуре объектов.
3. Зачастую нужен доступ ко всем перегруженным методам, а не только к методу одного последнего предка. В моей либе все когда либо примешанные методы сохраняются в прототипе по тому самому глобальному идентификатору.
По ссылке больше примеров)
Множественное наследование — это безусловно классно, но есть ряд проблем:
1. Конфликты имён. Не должны методы одной примеси молча затирать методы другой. В моей либе вместо затирания происходит создания метода-конфликта. Чтобы разрешить конфликт нужно примешать такой метод в описании которого указано, что он пригоден для разрешения конфликта между теми конфликтующими методами.
2. Не всегда понятно какой метод/свойство взяты из какой примеси/класса. В моей либе каждый метод имеет глобальный идентификатор. А также есть функция которая раздаст идентификаторы уже готовой структуре объектов.
3. Зачастую нужен доступ ко всем перегруженным методам, а не только к методу одного последнего предка. В моей либе все когда либо примешанные методы сохраняются в прототипе по тому самому глобальному идентификатору.
По ссылке больше примеров)
+1
Не холивара ради, но множественное наследование говорит лишь о проблемах в обсерватории. Мне много где приходилось применять обычное наследование (одиночное, хоть на прототипах, хоть классическое), и много делал полезных примесей, которые придают объекту определённые «способности» (удачно подобранное выражени в статье). Но множественное наследование — это перебор. IMHO.
+1
И чем же множественное примешивание отличается от множественного наследования? х)
Я вот каких только вариантов повторного использования кода не перепробовал, но остановился на таком:
Есть типажи (штрихи/примеси/классы), они по умолчанию ничего не умеют.
Для типажей можно определять методы.
Типажи могут быть примешаны друг ко другу. При этом ранее определённые и позже определяемые в предках методы также копируются и в потомков каскадно.
В качестве типажей могут быть использованы любые глобально доступные объекты.
Каждый метод хранит информацию о том, какие методы он умеет перегружать.
Одноимённые методы определяемые в одном типаже проходят через процедуру «слияния».
Результатом «слияния» является либо один из методов (который должен уметь перегружать всех оставшихся), либо автоматически генерируемый метод-конфликт, хранящий в себе информацию о конфликтующих методах. Совсем как в системах контроля версий: типаж — это фичеветка.
Я вот каких только вариантов повторного использования кода не перепробовал, но остановился на таком:
Есть типажи (штрихи/примеси/классы), они по умолчанию ничего не умеют.
Для типажей можно определять методы.
Типажи могут быть примешаны друг ко другу. При этом ранее определённые и позже определяемые в предках методы также копируются и в потомков каскадно.
В качестве типажей могут быть использованы любые глобально доступные объекты.
Каждый метод хранит информацию о том, какие методы он умеет перегружать.
Одноимённые методы определяемые в одном типаже проходят через процедуру «слияния».
Результатом «слияния» является либо один из методов (который должен уметь перегружать всех оставшихся), либо автоматически генерируемый метод-конфликт, хранящий в себе информацию о конфликтующих методах. Совсем как в системах контроля версий: типаж — это фичеветка.
0
Множественное примешивание — это простая операция, которая не сохраняет информацию о перегрузках методов, она их просто перекрывает и всё. После примешивания вы не можете обратиться к источнику примеси (т.к. это не требуется), и не можете знать какой источник предпоследний и т.д. В общих словах, вы ориентируетесь на результат без истории его возникновения.
0
Из пальца высосал разницу)
Ну и что хорошего в этаком примешивании? Скорость? Одинаково. Потребление памяти? Одинаково. Простота реализации? А толку от простоты, если она приводит к трудноуловимым багам? По твоему ловить глюки, вызванные конфликтом методов, лучше, чем вменяемое сообщение о конфликте? Или писать костыли, когда нужно не просто переопределить метод, а дополнить?
Ну и что хорошего в этаком примешивании? Скорость? Одинаково. Потребление памяти? Одинаково. Простота реализации? А толку от простоты, если она приводит к трудноуловимым багам? По твоему ловить глюки, вызванные конфликтом методов, лучше, чем вменяемое сообщение о конфликте? Или писать костыли, когда нужно не просто переопределить метод, а дополнить?
0
Хорошего именно простота логики, не надо заботиться о что откуда почему пришло и как это себя поведёт если… Не стоит усложнять там, где это не требуется, и стоит упрощать там, где это возможно.
Я не спорю, что бывают задачи разные и разные подходы к их решению, и каждому унструменту свою задачу. Я высказал своё мнение, что я лучше разобью логику на более простые составляющие, чем буду применять «множественное наследование», и да, я считаю, что если это самое множественное наследование применяется повсеместно, то стоит пересмотреть подходы к проектированию/программированию.
Серебряной пули не существует, на этом давайте и закончим, и без того затянувшийся и слишком абстрактный разговор.
Я не спорю, что бывают задачи разные и разные подходы к их решению, и каждому унструменту свою задачу. Я высказал своё мнение, что я лучше разобью логику на более простые составляющие, чем буду применять «множественное наследование», и да, я считаю, что если это самое множественное наследование применяется повсеместно, то стоит пересмотреть подходы к проектированию/программированию.
Серебряной пули не существует, на этом давайте и закончим, и без того затянувшийся и слишком абстрактный разговор.
0
Вот так вот не беспокоятся, а потом тратят на дебаг в 3 раза больше времени. Потому что беспокоиться о том что откуда пришло — необходимо. Потому, что нужно точно знать какие методы будут у объектов и как они будут действовать. Когда ты примешиваешь две пимеси, то у тебя возникает неопеделенность, которая сейчас работает как надо, а потом может сломаться. А находить такие баги довольно проблематично. Да и для разрешения конфликта используется как правило копипаста, либо хитрые конструкции типа Ext.Window.superclass.initConstructor.apply( this, arguments ) которые как ни странно ещё и работают через жопу.
И ничего во множественном наследовании плохого нет. Бывает плохая декомпозиция, да.
И ничего во множественном наследовании плохого нет. Бывает плохая декомпозиция, да.
+2
А меня вот эта запись смущает. Вроде, всё правильно, и даже цепочки прототипов есть (prototype.prototype...), но что-то сильно не нравится, не пойму что.
var Animal = function(){
this.prototype = new function(){
this.walk = true;
}
}
var Cat = function(){
this.prototype = new Animal();
}
console.log(new Cat().prototype.prototype.walk); //true
var Animal = function(){
this.prototype = new function(){
this.walk = true;
}
}
var Cat = function(){
this.prototype = new Animal();
}
console.log(new Cat().prototype.prototype.walk); //true
-2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Понимание ООП на джаваскрипте (ES5), часть 2