твоя личная формулировка, словесная эквилибристика (которой все, что хочешь можно доказать) =) не будем в этом ключе — все равно толку нет.
Можно другую формулировку — классовый язык — такой язык, в котором существует понятие «класс» — не важно — динамический, статический, выступающий фабрикой, заводом и т.д.
ну, кардинально отходить от терминологии с элементами отсебятины, — я так не смогу рассуждать ;)
В Питоне — существует понятие «Динамический класс, порождающий инстансы», инстансы делегируют к классу (подобно в JS к прототипу конструктора), за исключением некоторых особенностей.
> но и о вещах, которые важны для языка как инструмента
какие конкретно вещи интересуют?
— инкапусляция? — строгой нет, и быть не может (var'ы тоже хаком можно достать, если потребуется)
— наследование? — изначально заложено в JS (еще можно ни одной серьезной строчки кода не написать, а наследование уже во всю работает — 1.toString() — как Вы объясните это поведение? Что здесь происходит?)
— полиморфизм? — можно перегружать методы (поиск в цепи прототипов остановится на первом найденном методе), можно вызвать одноименные родительские, если сделать ссылку на родительский конструктор (или его прототип — как удобней)
— можно динамически менять предков — меняя прототип (подобного эффекта можно также добиться агрегацией)
> в чем prototype-стиль оказывается дает ощутимые преимущества относительно class-стиля.
динамика, делегирование, расшаривание одних сущностей между порожденными объектами
Статические классы — быстрее, менее ресурсоемки, но, вместе с тем, — менее гибки.
> немного выше Zeroglif писал, что сама концепция проще. ну да, согласен,
а где именно Вы согласны? Zeroglif за себя говорил, а что Вам показалось проще?
> но при этом код проще ну никак не выглядит.
да какие проблемы? опишите функцию, добавьте методы в прототип:
> У абстракцыи главное что? Главное — не смотреть унутрь, на детали!
Балин =) Это верно! (вот как поспорить с такой фразой? Особенно, если абстракция уже не ближней стадии, а в пятом поколении. — Только разработчики смотрят внутрь движка JS, пользователи JS — лишь немногие). Но — не запрещено смотреть, особенно, если интересует суть ;)
> Как оно там внутре реализовано, значения не имеет.
что значит, не имеет? именно это и имеет значение, раз речь идет о прототипном языке. Моя главная мысль, чтобы новички — смотрели на обертки, как на обертки (ни больше, ни меньше) и одновременно с этим не думали, про классовое ООП, как о «пугале».
да то же самое будет =) там специальная фишка есть — все так же можно в прототип выносить:
dynamic class A {
function test() {}
prototype function test2() {}
}
var a = new A();
var b = new A();
print a.test === b.test; // false
print a.test2 === b.test2; // true
> Что-то не вижу бенефитов от приделывания Simula-style OOP к JS. Ну в упор не разгляжу что-то.
а где Вы вообще увидели Симула-стайл? Я как раз на протяжении всех комментов, говорю, что все это можно делать без оберток, и говорю, что внутри оберток — все те же прототипы.
Двигатель прогресса — это мысли идеологов, это идеи созидателей. При этом ими движет — нет, не лень (простите, это — чушь), ими движет желание увидеть, что будет дальше. Они осознают, что, если будут использовать текущую абстракцию — могут не успеть, поэтому садятся, и пишут еще более совершенную. Далее, тратят меньше времени.
Потребители же, — могут говорить — «лень — двигатель прогресса» (при этом, не являясь создателями этих «благ»). Да-да, это им (потребителям) принадлежат фразы типа «зачем создавать велосипед, когда можно пользоваться готовым?». Кстати, в этом нет ничего плохо — потребители дальше сами становятся созидателями и идеологами. Вот здесь чуть-чуть излагал эту мысль. (PS: это лишь мое видение)
> Если Вас спасают классы и наследование — пользуйтесь на здоровье.
Я больше теоретик (идеолог), и больше изучаю, чем использую. Любая абстрактная вещь — мне интересна, я ее мало конкретизирую.
> Однако, не во всех классовых организациях, я полагаю, используется каскадная модель — см. пример из ES4 выше
путанная фраза получилась, я имею в виду, что в ES4 в данном случае как раз-таки получается (с виду, я не в курсе оптимизаций внутри движка и спецификацию ES4 не читал) каскадная модель
> хорошо, но есть какие-то исследования, замеры? заметен ли выигрыш по ресурсам?
Однозначно, — делегирующая модель жрет памяти в n-раз меньше, относительно каскадной модели. Однако, не во всех классовых организациях, я полагаю, используется каскадная модель — см. пример из ES4 выше, когда у каждого из инстансов появился свой метод «test». А если инстансов будет 10000? Есть разница? 10000 объектов или один? Но и тут, я склонен полагать, что какая-то оптимизация используется.
В свою очередь делегирующая модель медленней — поскольку нужно просмотреть всю цепь прототипов, если искомая проперть окажется на самой «глубине».
> вот, например, я смотрю на код, который вы написали ниже, и мне кажется (может я и ошибаюсь конечно), что он многословный, неинтуитивный. ну не вижу я преимуществ
Ну это организация наследования без оберток. Вам значит удобней использовать обертку. Просто имейте в виду (нет, — знайте!), что внутри обертки mootools'a — то же самое.
> если его переписать под чистый незамутненный prototype-based, он станет лучше?
относительно ресурсов — станет быстрей, относительно удобочитаемости — каждый сам решает, в целом — лучше-не лучше — а то же самое.
зависит от реализаций, я полагаю; вот, к примеру, из ES4 код ниже — здесь не делегация, каждый инстанс имеет свой метод «test» (я не знаю, как это реализовано на уровне движка, может делается какая оптимизация и это, на самом деле, один метод, но тем не менее, в JS — у каждого объекта — свой одинаковый по семантике метод)
Да не пугают они меня вовсе, я знаю, что на них отвечать, а если не знаю — ищу знаний. Насчет мэйнстримовых трендов — если институты слишком большие (типа jQuery) — да, ну уровне локальных высказываний на форумах, мало что решается (хотя… почему нет?). В целом же — эти «десять человек» в любом случае помогают, показывают, что стоит за «всем этим».
Касательно самого понятия тренд — а что, сам JS не был трендом в свое время (да и сейчас тоже)? Тут главное — позиция: «объект тренд — поэтому он крут», «либо объект — крут, поэтому — он тренд».
Поправлюсь про «высказывания» — естественно, нет ничего плохого, чтобы принять позицию высказывания профи, и потом использовать эти слова (поскольку, если человек профи — его слова в 97-100% истинны относительно того, о чем он рассуждает; как говорил кто-то там (не помню) — «все, что сказано красиво (а в данном случае, грамотно), я считаю своим»). Я лишь к тому, что надо быть всегда готовым поддержать свои слова и, в случае утверждений, обязательно иметь четкое представление о предмете.
Можно другую формулировку — классовый язык — такой язык, в котором существует понятие «класс» — не важно — динамический, статический, выступающий фабрикой, заводом и т.д.
ну, кардинально отходить от терминологии с элементами отсебятины, — я так не смогу рассуждать ;)
В Питоне — существует понятие «Динамический класс, порождающий инстансы», инстансы делегируют к классу (подобно в JS к прототипу конструктора), за исключением некоторых особенностей.
function MyClass() {}
MyClass.prototype = {
method1: function () {},
method2: function () {},
и т.д.: что-то там
};
var a = new MyClass();
a.method1();
a.method2();
какие конкретно вещи интересуют?
— инкапусляция? — строгой нет, и быть не может (var'ы тоже хаком можно достать, если потребуется)
— наследование? — изначально заложено в JS (еще можно ни одной серьезной строчки кода не написать, а наследование уже во всю работает — 1.toString() — как Вы объясните это поведение? Что здесь происходит?)
— полиморфизм? — можно перегружать методы (поиск в цепи прототипов остановится на первом найденном методе), можно вызвать одноименные родительские, если сделать ссылку на родительский конструктор (или его прототип — как удобней)
— можно динамически менять предков — меняя прототип (подобного эффекта можно также добиться агрегацией)
> в чем prototype-стиль оказывается дает ощутимые преимущества относительно class-стиля.
динамика, делегирование, расшаривание одних сущностей между порожденными объектами
Статические классы — быстрее, менее ресурсоемки, но, вместе с тем, — менее гибки.
> немного выше Zeroglif писал, что сама концепция проще. ну да, согласен,
а где именно Вы согласны? Zeroglif за себя говорил, а что Вам показалось проще?
> но при этом код проще ну никак не выглядит.
да какие проблемы? опишите функцию, добавьте методы в прототип:
function MyClass() {}
Балин =) Это верно! (вот как поспорить с такой фразой? Особенно, если абстракция уже не ближней стадии, а в пятом поколении. — Только разработчики смотрят внутрь движка JS, пользователи JS — лишь немногие). Но — не запрещено смотреть, особенно, если интересует суть ;)
что значит, не имеет? именно это и имеет значение, раз речь идет о прототипном языке. Моя главная мысль, чтобы новички — смотрели на обертки, как на обертки (ни больше, ни меньше) и одновременно с этим не думали, про классовое ООП, как о «пугале».
dynamic class A { function test() {} prototype function test2() {} } var a = new A(); var b = new A(); print a.test === b.test; // false print a.test2 === b.test2; // trueХотя, какая разница, все равно ES4 не прижился.
а где Вы вообще увидели Симула-стайл? Я как раз на протяжении всех комментов, говорю, что все это можно делать без оберток, и говорю, что внутри оберток — все те же прототипы.
Двигатель прогресса — это мысли идеологов, это идеи созидателей. При этом ими движет — нет, не лень (простите, это — чушь), ими движет желание увидеть, что будет дальше. Они осознают, что, если будут использовать текущую абстракцию — могут не успеть, поэтому садятся, и пишут еще более совершенную. Далее, тратят меньше времени.
Потребители же, — могут говорить — «лень — двигатель прогресса» (при этом, не являясь создателями этих «благ»). Да-да, это им (потребителям) принадлежат фразы типа «зачем создавать велосипед, когда можно пользоваться готовым?». Кстати, в этом нет ничего плохо — потребители дальше сами становятся созидателями и идеологами. Вот здесь чуть-чуть излагал эту мысль. (PS: это лишь мое видение)
> Если Вас спасают классы и наследование — пользуйтесь на здоровье.
Я больше теоретик (идеолог), и больше изучаю, чем использую. Любая абстрактная вещь — мне интересна, я ее мало конкретизирую.
путанная фраза получилась, я имею в виду, что в ES4 в данном случае как раз-таки получается (с виду, я не в курсе оптимизаций внутри движка и спецификацию ES4 не читал) каскадная модель
Однозначно, — делегирующая модель жрет памяти в n-раз меньше, относительно каскадной модели. Однако, не во всех классовых организациях, я полагаю, используется каскадная модель — см. пример из ES4 выше, когда у каждого из инстансов появился свой метод «test». А если инстансов будет 10000? Есть разница? 10000 объектов или один? Но и тут, я склонен полагать, что какая-то оптимизация используется.
В свою очередь делегирующая модель медленней — поскольку нужно просмотреть всю цепь прототипов, если искомая проперть окажется на самой «глубине».
> вот, например, я смотрю на код, который вы написали ниже, и мне кажется (может я и ошибаюсь конечно), что он многословный, неинтуитивный. ну не вижу я преимуществ
Ну это организация наследования без оберток. Вам значит удобней использовать обертку. Просто имейте в виду (нет, — знайте!), что внутри обертки mootools'a — то же самое.
> если его переписать под чистый незамутненный prototype-based, он станет лучше?
относительно ресурсов — станет быстрей, относительно удобочитаемости — каждый сам решает, в целом — лучше-не лучше — а то же самое.
С этого места поподробней (про ленивых), пожалуйста. Насколько глубоко Вы знаете JS?
.python: my_obj = { 'a': 10, 'test': lambda x: x + 10, 'b': 20 } my_obj['a'] # 10 my_obj['test'](10) # 20 my_obj['b'] # 20опять масло масляное получается вроде =) а может быть и нет
Касательно самого понятия тренд — а что, сам JS не был трендом в свое время (да и сейчас тоже)? Тут главное — позиция: «объект тренд — поэтому он крут», «либо объект — крут, поэтому — он тренд».