С CoffeScript не сравнивал, но в нем используется наследование по методу Дугласа Крокфорда (функция extend). Могу предположить, что будет на уровне с остальными фреймворками, но если хотите быть уверенным — то лучше проверить самому.
Разрешите уточнить:
Правильно будет именно копировать функции, или же достаточно все начальные значения присваивать в конструкторе, а из прототипа убрать? (все-равно конструктор генерируется)
Теперь вижу, еще раз благодарю за консультацию, буду улучшать производительность.
Только у меня падение скорости не в 2 раза, а так:
Lava method call in child class (client generated class) = 13,498
Lava method call in child class (server generated class) = 11,233
Lava method call (2) = 9,283
В том и дело, что ваш Lava method call (2) исполняется ровно с такой же скоростью как и остальные.
А в Firefox он вообще в 2 раза быстрее всех остальных.
Для полной картины все таки желательно собрать побольше фреймворков. В статье было упомянуто, что если прототип присвоить как объект, то в Firefox падает скорость создания классов. Возможно, какие-то фреймворки используют Object.create — это обязательно будет влиять на скорость, или может знают некоторые хитрости, чтоб ускорить свои классы в определенных браузерах…
ClassManager и TypeScript — это два разных инструмента, которые решают одну и ту же задачу разными способами.
TypeScript крут! Поддержка IDE, рефакторинг… но вот те, кто сидят на линуксе — не пользуются IDE от Microsoft. Лично мне без разницы, у меня стоит Visual Studio. Давайте поищем более существенные отличия.
В комментарии выше я уже упоминал, что классы из моего фреймворка можно monkey-патчить, а в случае TypeScript, если не ошибаюсь, то вам нужно заменить весь файл с классом. То есть в моем случае у вас больше контроля.
ClassManager позволяет патчить классы во время выполнения, а TypeScript нет.
Ну и, наконец, разница в скорости.
Какой инструмент выбрать — чаще всего зависит от решаемой задачи.
«костыльным»? извините, но мой синтаксис не более «костыльный» чем синтаксис ES6. Когда вы видите мой класс — вы точно знаете, что будет сгенерировано.
Мой инструмент решает реальные задачи реальных людей. Если вам так важно видеть синие слова «public» «get» и «constructor» в IDE, то вам мой инструмент не нужен, пользуйтесь ES6.
Есть весомая причина: в вашем примере ParentClass уже должен существовать на момент вызова define.
А с моим подходом я складываю тела классов в массив Lava.classes, и сами классы создаю уже в Lava.init().
Отложенное создание позволяет сделать monkey-патчинг для классов ядра (кто знает, что может понадобиться программистам, которые будут мой продукт использовать).
В вашем подходе этого делать нельзя, в лучшем случае заменяется целый файл в сборке, а в моем — можно заменить даже метод в классе, который находится в начале цепочки наследования, причем не изменяя файлы проекта.
1) В JavaScript я начинал именно с MooTools и ООП. У меня были большие проекты, где нужна надежность и качество, так что ООП — это красота и спасение, а не зло. Трудности возникают если есть лапша неструктурированного кода, которую приходится переписывать.
2) Конечно, можно. Разрешите пригласить вас в исходник основного фреймворка
— там больше 100 классов, которые решают задачи из реальной жизни.
Пример свойств по умолчанию:
Lava.define('Lava.Something', {
// все это будет скопировано для каждого экземпляра класса
name: "Вася",
names: ["Коля", "Петя"],
number: 123
});
Инкапсуляция не нарушается. Приватный член класса — он так же является и защищенным, но с более сильными ограничениями.
Когда пишешь большое приложение на том же C++ — то почти все члены класса у вас будут именно защищенными, а не приватными, согласны?
Другие дело, что в JavaScript за настоящую приватность вы платите слишком большую цену, разговор был именно об этом, так что другими словами обмен получается невыгодным.
Да прекрасно работает, только что даже проверил чтоб быть уверенным.
Там простой объект в стандартной обертке…
if (typeof module != 'undefined' && module.exports) {… } else { _global.Lava = Lava; }
Когда начинал работу над ClassManager, то от Object.create сразу отказался — хотел поддерживать IE8. Спасибо что напомнили, померяю скорость, но результат мы получим тот же, так что для меня разницы нет.
Что насчет поддержки старых браузеров — то на начальной стадии она точно была, и сейчас скорее всего есть, но чтоб быть уверенным — стоит проверить заново.
Судя по таблицам его поддержки мы не будем им пользоваться в ближайший год. Судя по спецификации — классы ES6 — это синтаксический сахар над прототипами, и мне будет интересно сравнить их производительность со своим решением. Вообщем, пока ES6 наступит мне на пятку — я еще успею завоевать немного популярности :) И продукт развивается, так что время у меня еще есть.
Правильно будет именно копировать функции, или же достаточно все начальные значения присваивать в конструкторе, а из прототипа убрать? (все-равно конструктор генерируется)
Только у меня падение скорости не в 2 раза, а так:
Lava method call in child class (client generated class) = 13,498
Lava method call in child class (server generated class) = 11,233
Lava method call (2) = 9,283
А в Firefox он вообще в 2 раза быстрее всех остальных.
Как я понимаю, тот факт что this.counter берется из прототипа на производительность не повлиял — по крайней мере, в этом тесте.
ClassManager и TypeScript — это два разных инструмента, которые решают одну и ту же задачу разными способами.
TypeScript крут! Поддержка IDE, рефакторинг… но вот те, кто сидят на линуксе — не пользуются IDE от Microsoft. Лично мне без разницы, у меня стоит Visual Studio. Давайте поищем более существенные отличия.
В комментарии выше я уже упоминал, что классы из моего фреймворка можно monkey-патчить, а в случае TypeScript, если не ошибаюсь, то вам нужно заменить весь файл с классом. То есть в моем случае у вас больше контроля.
ClassManager позволяет патчить классы во время выполнения, а TypeScript нет.
Ну и, наконец, разница в скорости.
Какой инструмент выбрать — чаще всего зависит от решаемой задачи.
Мой инструмент решает реальные задачи реальных людей. Если вам так важно видеть синие слова «public» «get» и «constructor» в IDE, то вам мой инструмент не нужен, пользуйтесь ES6.
А с моим подходом я складываю тела классов в массив Lava.classes, и сами классы создаю уже в Lava.init().
Отложенное создание позволяет сделать monkey-патчинг для классов ядра (кто знает, что может понадобиться программистам, которые будут мой продукт использовать).
В вашем подходе этого делать нельзя, в лучшем случае заменяется целый файл в сборке, а в моем — можно заменить даже метод в классе, который находится в начале цепочки наследования, причем не изменяя файлы проекта.
2) Конечно, можно. Разрешите пригласить вас в исходник основного фреймворка
— там больше 100 классов, которые решают задачи из реальной жизни.
Пример свойств по умолчанию:
Когда пишешь большое приложение на том же C++ — то почти все члены класса у вас будут именно защищенными, а не приватными, согласны?
Другие дело, что в JavaScript за настоящую приватность вы платите слишком большую цену, разговор был именно об этом, так что другими словами обмен получается невыгодным.
Там простой объект в стандартной обертке…
if (typeof module != 'undefined' && module.exports) {… } else { _global.Lava = Lava; }
Что насчет поддержки старых браузеров — то на начальной стадии она точно была, и сейчас скорее всего есть, но чтоб быть уверенным — стоит проверить заново.