Использование классов в JavaScript

[devote]

B~Vladi,
вот спасибо добрый человек. Почитаю на досуге что к чему, я так понимаю IDE нужно для этого дела то.. Видимо придется поставить.

[B~Vladi]

я так понимаю IDE нужно для этого дела

Нет, не нужно. IDE даст тебе только автокомплит (как в коде, так и при написании jsdoc), а генерировать саму доку нужно отдельной утилитой, ссылку на которую я тебе давал выше. Если вообще захочешь генерировать.

[devote]

а отлично, покумекаю над этим на досуге.. Доку то надо начирикать какую то.

[x-yuri]

Есть тут свои тонкости, конечно же нет возможности создания интерфейсов, абстракции и прочих полноценных прелестей ООП.

хм.. что-то не так написал? могу исправить если я в чем-то ошибаюсь.

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

честно говоря над методом Class.autoload нужно еще поработать, мне конечно не совсем пока нравится как это работает. Поэтому в будущих версия этот метод возможно претерпит изменения.

насчет обработки ошибок (Class.imports) тоже вполне возможно будут изменения, но пока не решил как улучшить и т.д.

что не нравится?

Правильнее было бы назвать это пространством имён.

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

а вообще внутри библиотеки указаны примеры создания:

аж 12 вариантов:

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

Class('MyClass', {
    myMethod: function() {...},
    ...
}, {context: '...', staticData: {...}});

т.е. такая сигнатура: Class(name, data, options)

И по поводу extends/implements/include (наследование), их можно туда же засунуть. Или прямо в data, зарезервивовав для служебных целей, например, двойное подчеркивание:

Class('MyClass', {
    __extends: 'MyBaseClass',
    __implements: 'MyMixin',
    __construct: function() {...},
    myMethod: function() {...}
});

[B~Vladi]

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

Нужно просто правильно сформулировать это в доках.

[devote]

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

ясно, перепишу позже иначе.

что не нравится?

ну то что autoload можно назначить лишь раз для всех скриптов, и входные параметры возможно сменю.. Нужно наверно добавить во входной параметр и имя класса который пытается найти нужный ему класс.. Хотя над этим еще подумаю. Насчет imports пока сложно сказать что не так, но явно что-то не так.

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

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

Или прямо в data,

Насчет implments я его не реализовывал, пока не вижу в нем необходимости, множественное наследование не так часто нужно поэтому над этим еще нужно покумекать.

При всем этом я писал из расчета скорости работы, если я напишу так как вы предлагаете во втором варианте, тоесть прямо в data это приведет к тому что при создании экземпляра нужно будет каждый раз разбирать все эти параметры, что приведет к занижению производительности. Хоть она и не заметна будет, но для большого кода/проектов это значительные потери. В моей же реализации, все манипуляции с параметрами происходят во время объявления класса, далее уже при создании экземпляров, никакие параметры не разбираются.
Допустим:

Class("Foo", Parent, { // вот именно в этот момент идет разбор параметров
    // some code
});

// никакого разбора не происходит, но ищутся такие
// свойства как setters/getters затем складываются в
// специальный стек
var a = new Foo();

// при втором обращении, уже ничего вообще не делается
// а все сеттеры/геттеры берутся из стека, что увеличивает
// скорость работы конструктора.
var b = new Foo();

Нужно просто правильно сформулировать это в доках.

Насчет доков я все же посмотрел JSDoc и попробовал, честно скажу паршивая это штука. Совсем не понятно делает доку. Без пива сложно понять. Хотя дело привычки конечно. Но и описании в коде под него нужно хорошо заточить, что бы он все подряд в доку не совал. Как это произошло у меня, все приватные и внутренние методы сунул в доку, что не есть гуд.

[B~Vladi]

все приватные и внутренние методы сунул в доку, что не есть гуд.

Юзай @private или @ignore.

Совсем не понятно делает доку.

Если разобраться, то всё становится понятным.

[devote]

Если разобраться, то всё становится понятным.

ну дык я и говорю, без пива не разберешь А так да, время лечит.

[x-yuri]

ну то что autoload можно назначить лишь раз для всех скриптов, и входные параметры возможно сменю.. Нужно наверно добавить во входной параметр и имя класса который пытается найти нужный ему класс.. Хотя над этим еще подумаю.

Да, несколько раз было бы удобнее. По поводу параметров, не знаю, зачем может понадобиться что-то кроме имени класса, который надо подгрузить. Хотя дополнительная информация наверное не помешает.

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

Что ж в нем сложного-то? Использование объекта (ассоц. массива) вместо перечисления параметров через запятую? В твоём варианта рассчет идет на очевидность, с целью сэкономить на "назывании параметров". Экономия очень сомнительная на мой взгляд. Чем больше параметров, тем сомнительнее. Так почему бы не расслабиться и не использовать мой вариант? А твой подход использовать, в более простых случаях? Кстати, я бы назвал его jQuery-подходом.

При всем этом я писал из расчета скорости работы, если я напишу так как вы предлагаете во втором варианте, тоесть прямо в data это приведет к тому что при создании экземпляра нужно будет каждый раз разбирать все эти параметры, что приведет к занижению производительности. Хоть она и не заметна будет, но для большого кода/проектов это значительные потери. В моей же реализации, все манипуляции с параметрами происходят во время объявления класса, далее уже при создании экземпляров, никакие параметры не разбираются.

Во-первых, кеширование никто не отменял. Во-вторых, это ваше классовое ООП странновато смотрится в прототипно-ориентированном ЯП. Альтернатива: mixin, inherit. Разве этого не достаточно? На фоне альтернативного варианта твоя библиотека выглядит ненужным усложнением (в первую очередь интересны __get/__set и autoload, ну и imports), и тут мне в очередной раз приходит в голову мысль, что большинство проблем с производительностью связаны с неоправданно высокими требованиями (ненужными усложнениями)...

[devote]

Да, несколько раз было бы удобнее. По поводу параметров, не знаю, зачем может понадобиться что-то кроме имени класса, который надо подгрузить. Хотя дополнительная информация наверное не помешает.

вот и я о том же.

Что ж в нем сложного-то? Использование объекта (ассоц. массива) вместо перечисления параметров через запятую?

Ну я не сказал что отказываюсь от решения, конечно покумекаю над этим, и обязательно реализую это.

Во-вторых, это ваше классовое ООП странновато смотрится в прототипно-ориентированном ЯП

Никто и не утверждает обратного.