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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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