Классы в Javascript: вызов методов родительского класса

Я сам всё нашёл. Вот тут: mootools.net/downloads/mootools-1.2-core-nc.js в коментах написано:

Inspiration:
— Class implementation inspired by [Base.js](http://dean.edwards.name/weblog/2006/03/base/) Copyright © 2006 Dean Edwards, [GNU Lesser General Public License](http://opensource.org/licenses/lgpl-license.php)

Так что MooTools можно и не выделять — оно основано на реализованном в base2

Да, он на форуме от статьи отрёкся.

Используют, используют — Psih уже назвал меня гуру (только… ник у него подозрительный =)

Да что вы все привязались — «чужеродная парадигма, чужеродная парадигма! классы не нужны!» =) и что с того, что на данный момент в JS только делегирующая прототипная модель наследования? — ну нравится человеку называть свою обертку «классами». Ведь по сути, использует-то он для реализации этой обертки все ту же делегирующую к прототипам конструкторов модель. И не важно, как он это называет — Class, _class, moyaUdobnayaObyortkaDlyaPrototypnogoNasledovaniya или еще как — *суть не меняетя*! Главное, — что человек понимает, *что* он пишет *и для чего*.

[.quote: «#Zork 25 сентября 2008, 16:43 „]
> А чем мешает прототипное наследование? Оно же, как бы язык то другой, парадигма как бы тоже другая, зачем с++ опять городить?

Так все и используют *единственное* prototype-based inheretance (другого нет), просто называют свои обертки, как им удобно.

Другое дело (и вот это, действительно, очень жаль), когда человек может нести всякий бред, говоря: я выучил JS по Prototype.js (или jQuery/Mootools/Ext — не важно) и при этом еще может начать яро доказывать, что в JS есть классы (т.к. Class.create() =))

А еще жаль, когда человек ведется на подобные классы в виду недостаточного количества информации, часто даже не признавая механизм протоипного наследования альтернативой классовому — вот в этом случае подобные статьи могут сыграть не положительную роль.

P.S. ES4 (JS2), к сожалению (или к счастью =)) обломался, так что классов пока не будет :( Но ведь их планировали. Хотя они были бы похожи на классы из Руби и Питона (динамическая часть классов, т.к. планировались еще и неизменяемые, как в C++). Да, вот хороший пример — Питон — там есть классы, но там так же можно динамически менять слоты класса (аналогия — смена слотов в протоипе конструктора в JS) и слоты порожденного инстанса (как и в JS).

Ну я не думаю, что наличии статических Java-классов — признак того, что язык стал для «программистов», а не для «разработчиков интерфейсов и дизайнеров» =) Мне видится это заблуждением.

Возьмем, к примеру, Python (а конкретно, — его построение классов; — это для тех, кто любит придраться к словам и начнет мне сейчас говорить — «нашел, что сравнивать — Питон и JS!» — повторю — только лишь *абстрактно* — работу классов в Питоне). Так вот — абстрагируемся от технической реализации (хотя, там так же налицо — делегация — если свойство не найдено в родном объекте, его поиск продолжается в цепи классов (цепи прототипов конструкторов в JS)):

Py:

# создали класс A, присвоили инстанс-свойству «а» значение 10 (__init__ — играет роль «конструктора»)

class A(object):
def __init__(self):
self.a = 10

JS:

// аналог на JS (вместо понятия «класс» — функция-конструктор)

function A() {
this.a = 10;
}

Py:

# класс B, наследуемый от А, self-свойство «b» = 20

class B(A): # наследование
def __init__(self):
self.b = 20
A.__init__(self)

JS:

// аналог на JS

function B() {
this.b = 20;
B.superClass.prototype.constructor.call(this, arguments);
}

// наследование (имеем возможность достучаться через цепь прототипов до нужного свойства)

var __inheritance = function() {};
__inheritance.prototype = A.prototype;
B.prototype = new __inheritance();
B.prototype.constructor = B;
B.superClass = A; // явная ссылка на «А» для вызова родительских методов

Далее, объекты-инстансы:

obj = B() # Py:
var obj = new B() // JS:

print obj.a, obj.b # 10, 20 — self-свойства
alert([obj.a, obj.b]) // 10, 20 — this-свойства

Расширяем класс в Питоне и прототип конструктора в JS новым слотом:

A.c = 30 # Py:
A.prototype.c = 30 // JS:

Свойство посредством делегирования (во всяком случае в JS) доступно через конструкцию «роднойОбъект.свойство»

print obj.c # Py: 30
alert(obj.c) // JS: 30

Добавляем новые родные свойства:

obj.d = 40 # Py: 40
obj.d = 50 // JS: 40

Добавляем свойство с таким же именем в класс (Питон) и прототип конструктора (JS) — на сей раз — «B»:

B.d = 70
B.prototype.d = 70

Пока берется родное «d»:

print obj.d # Py: 40
alert(obj.d) // JS: 30

Удаляем:

del obj.d #Py:
delete obj.d // JS:

А вот теперь — снова за счет делегирования из класса (прототипа конструктора):

print obj.d # Py: 70
alert(obj.d) // JS: 70

Так вот, Covex, скажите мне — разве Питон не язык «программистов»? В нем, как Вы видите, нет Java-классов.

А для тех, кто при выходе очередной статьи про «*оболочки* в виде классов в JS» не ленится каждый раз написать — «зачем классы?! это вам не С++!», скажите мне — где в примерах выше вы увидели С++? Тем не менее, приводились тоже классы. И, в виду того, что мы абстрагировались, визуальная разница — это наследование:

Py: class B(A):

JS:

var __inheritance = function() {};
__inheritance.prototype = A.prototype;
B.prototype = new __inheritance();
B.prototype.constructor = B;
B.superClass = A; // явная ссылка на «А» для вызова родительских методов

И вот, чтобы не писать каждый раз эту длинную конструкцию, люди делают свои обертки и называют их «классами», и, во всяком случае я, в этот момент не думают ни о каких классах из С++. Для меня это просто обертка, я знаю, что что бы я ни написал — внутри будет — *prototype-based inheritance*.

да, действительно баг:

            // super
            this.super = function (name) {
                return cls.super(this, name);
            }

идёт рекурсивный вызов, придётся убрать this.super и заменить на class.super

профиксил:

var Class = function(){};

Class.create = function(prop, cls_super){
    
    if (!cls_super){
        cls_super = Class;
    }
    
    var init = false;
    // new class
    var cls = function (){
        if (init) {
            // extend this
            this.extend = function (prop) {
                for (name in prop) {
                    this[name] = prop[name];
                }
                return this;
            }

            if (this.init) {
                this.init.apply(this, arguments);
            }
        }
    };

    cls.prototype = new cls_super();
    init = true;

    // extend class
    for (name in prop) {    
        cls.prototype[name] = prop[name];
    }

    cls.prototype.constructor = cls;

    // super
    cls.super = function(instance, name){
        var property = cls_super.prototype[name];
        if (property instanceof Function){
            return function () {return property.apply(instance, arguments)};
        } else {
            return property;
        }
    }

    // extend
    cls.extend = function(prop){
        init = false;
        var _cls = Class.create(prop, cls);
        init = true;
        return _cls;
    }
    
    return cls;
}

ваш код тогда будет выглядеть так:

var C1 = Class.create({ init: function() { alert("C1"); } });
var C2 = C1.extend({
 init: function() {
  alert("C2");
//  debugger;
  C2.super(this, 'init')();
 }
});

var C3 = C2.extend({ });
var C4 = C3.extend({
 init: function() {
  alert("C4");
  C4.super(this, 'init')();
 }
});

var obj = new C4();

вот думаю как сделать:
1) class.super(объект, имя_метода)
или
2) class.super(имя_метода, объект)

сейчас используется 1 вариант

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

то есть ты отрицаешь инкапсуляцию, как основополагающий принцип ооп? :-)

самое главное — написать простой, понятный, эффективный и легко поддерживаемый код. создание иерархии классов предназначено для создания понятного кода. но вот рефакторить код с «иерархией классов» довольно сложно: менять внутренности одного родителя можно только с постоянной оглядкой на всех детей.

подожди, что-то я не нашел четкого определения «штрих» (дай ссылку, пожалуйста)

> примеси — довольно глупая концепция разделения методов и данных
> штрихи — примеси без состояния

вообще, в определении примеси как раз говорится, о том, что состояние (данные) определены в классе, а поведение (методы) подмешиваются. В первой цитате ты называешь это глупой концепцией, а во второй определяешь «штрих» определением «примесь». Или я не правильно понял?