так ведь, если копнуть историю, можно вспомнить три момента:
1. Сначала был Netscape со своим JS и не было никакого DOM. Потом пришел MS со своим IE и показал, что IE4 — это круто, потому что у нас есть Jscript + DHTML (вот они, менюшки). И понеслась: в Netscape — layers, в MS — DHTML, HTA и прочие прибамбасы. В какой лагерь бежать — на тот момент было совершенно очевидно.
А вот потом уже появляется DOM, который оказался никому не нужен, кроме джавистов, потому что к моменту, когда рекомендация W3C была прочитана, усвоена и были созданы имплементации DOM — Netscape уже склеил ласты, а MS чхать хотел на мнение W3C.
2. VBscript, ActivePerl с такой плюшкой как client side Perl :) то что Javascript выжил, а остальные нет — скажем так, закон природы: vbs — слишком ущербен, ActivePerl появился не в неудачное время (тупо опоздали).
3. Думайте, как хотите, но не привязан DOM к какому-либо языку! DOM — это абстракция, методичка. Почитайте тот же W3C, что ли :)
Ну как же ж, очевидный плюс явной инкапсуляции в JS — невозможность достучаться туда «куда не следует» снаружи (из прикладного кода), чем гарантируется усточивость инкапсулированного компонента к внешним воздействиям.
Напротив, абсолютно лишний навык. Должен быть хороший инструмент (язык + компилятор), который решал бы эту задачу за программиста. Иначе программист становится придатком компилятора, а это неправильно.
Зная архитектуру и логику работы для Intel x86, что делать при портировании на ARM? Переписывать?
ребята, вы спорите ниочем. ООП — это всего лишь подход к разработке. ООП существует исключительно в голове разработчика и совершенно независит от какой-то конкретной реализации в том или ином языке. Реализация влияет исключительно на объем кода, который нужно написать для достижения результата. ООП можно делать хоть в процедурном стиле.
Не надо с ним спорить: товарищ явно не в теме. Pilat какбэ намекает, что в JS наследование декларируется явно через prototype (либо достигается копированием) и, поэтому, настоящим наследованием не считается, забывая при этом, что по сути RTTI == prototype.
P.S. с точки зрения кремня, ООП не существует, а существует только спагетти условных переходов | call, которые сбивают ему кэш и предсказатель переходов. ;-)
Итого, мы имеем конфликт интересов:
— с точки зрения пользователя, приоритет №1 — эффективность выполнения кода (aka скорость реакции железяки и минимизация времени на получение результов).
— с точки зрения разработчика, приоритет №1 — эффективность разработки и сопровождения кода.
Кто виноват? Что делать? (И кого бить?) ;-)
P.S. Добавил маленький бенчмарк, если интересно — можете погонять тесты (V8 жжот!, оверхед на лишний call ~= 2ms и это под VirtualBox). code.google.com/p/nulljs/wiki/HowtoPrivateMethods
> Супер красивый и логичный внутри, но приводящий к 0.5-1 секундным подвисаниям на каком-нибудь нетбуке код — нафиг никому не нужен.
Ок, план Б: рассмотрим браузерный JS как target-платформу и сделаем небольшой кросс-компилятор из красивого и логичного JS в некрасивый но эффективный JS для браузера ;-)
JS давно уже вышел за рамки браузера. Some buzzwords: SSJS, CouchDB, WSO2, Helma, jslibs, nekovm, mod_v8, llv8call.
1. Сначала был Netscape со своим JS и не было никакого DOM. Потом пришел MS со своим IE и показал, что IE4 — это круто, потому что у нас есть Jscript + DHTML (вот они, менюшки). И понеслась: в Netscape — layers, в MS — DHTML, HTA и прочие прибамбасы. В какой лагерь бежать — на тот момент было совершенно очевидно.
А вот потом уже появляется DOM, который оказался никому не нужен, кроме джавистов, потому что к моменту, когда рекомендация W3C была прочитана, усвоена и были созданы имплементации DOM — Netscape уже склеил ласты, а MS чхать хотел на мнение W3C.
2. VBscript, ActivePerl с такой плюшкой как client side Perl :) то что Javascript выжил, а остальные нет — скажем так, закон природы: vbs — слишком ущербен, ActivePerl появился не в неудачное время (тупо опоздали).
3. Думайте, как хотите, но не привязан DOM к какому-либо языку! DOM — это абстракция, методичка. Почитайте тот же W3C, что ли :)
RoR — это часть мира Ruby, потому что RoR без Ruby — не RoR :)
Аналогично: Django => Python, ZF => PHP, Hibernate => Java.
Теперь вопрос: существует ли DOM без JS? а JS без DOM?
Зная архитектуру и логику работы для Intel x86, что делать при портировании на ARM? Переписывать?
это наврятли
> преобразовывать красивый и логичный яваскрипт в быстрые команды должен браузер.
я изложил аналогичную мысль тремя листами выше ;-)
«Если создатели приложений, которыми я пользуюсь, ради своих архитектурных изысков накидывают на эту задержку ничем не обоснованные 200, 500 или 1000мс — я начинаю вспоминать разные нехорошие слова.» © depp
var person_talk = function (person) {
alert(«Hi, I'm » + person[0]);
};
var person_fight = function (person, target) {
alert(person[0] + ": I have no battle skills, so I run away from " + target[0]);
};
var doctor_heal = function (doctor, target) {
alert(doctor[0] + ": I spell heal on " + target[0]);
};
var mage_fight = function (person, target) {
alert(person[0] + ": I spell fireball on " + target[0]);
};
var talk = function (person) {
person[1](person);
};
var fight = function (person, target) {
person[2](person, target);
};
var heal = function (doctor, target) {
doctor[3](doctor, target);
};
var Person = function (name) {
return [name, person_talk, person_fight];
};
var Doctor = function (name) {
var p = Person(name);
p.push(doctor_heal);
return p;
};
var Mage = function (name) {
var d = Doctor(name);
d[2] = mage_fight;
return d;
};
var person = Person(«Barak Obama»),
house = Doctor(«House M.D.»),
aibolit = Doctor(«Aibolit»),
mage = Mage(«BlackMagic»);
talk(person);
fight(person, mage);
fight(mage, person); // специализация
heal(house, person);
fight(house, mage); // наследование
talk(mage);
P.S. с точки зрения кремня, ООП не существует, а существует только спагетти условных переходов | call, которые сбивают ему кэш и предсказатель переходов. ;-)
— с точки зрения пользователя, приоритет №1 — эффективность выполнения кода (aka скорость реакции железяки и минимизация времени на получение результов).
— с точки зрения разработчика, приоритет №1 — эффективность разработки и сопровождения кода.
Кто виноват? Что делать? (И кого бить?) ;-)
P.S. Добавил маленький бенчмарк, если интересно — можете погонять тесты (V8 жжот!, оверхед на лишний call ~= 2ms и это под VirtualBox). code.google.com/p/nulljs/wiki/HowtoPrivateMethods
Ок, план Б: рассмотрим браузерный JS как target-платформу и сделаем небольшой кросс-компилятор из красивого и логичного JS в некрасивый но эффективный JS для браузера ;-)