Стоит понимать, что JS — сам по себе — уже очень объектно-ориентированный язык. Данная «обертка» (JsOOP) в любом случае не имитирует статическую классовую парадигму. Это всего лишь обертка для существующего в JS динамического ООП, основанного на делегации к прототипам. Никакое статическое ООП здесь сделать нельзя (это невозможно в текущей версии JS).
Все то же самое (организовывать порождающий объект («класс») для других объектов («инстансов»), организовывать наследование, вызвать родительские перегруженные методы из объектом-потомков) вы можете делать и без этого синтаксического сахара. Единственное, для чего можно применять данные обертки — это сокращение записи наследования (подмена дефолтного прототипа конструктора на wrapper, чей прототип ссылается на прототип родительского объекта). Все. И в этих обертках реализовано именно это. Ничего другого и «магического» (а уж тем более, статических классов из Си и Java, которые являются альтернативной ООП-парадигмой — не лучше-не хуже прототипной модели) там нет.
В JS операторы || и && работают несколько иначе, чем в C/C++ или Java. Они возвращают результат второго (а в общем случае — следующего) операнда:
Запись
var Zoo = Zoo || {};
эквивалентна
if (window.Zoo) { // в общем случае someScope.object
Zoo = Zoo;
} else {
Zoo = {};
}
Аналогично с &&:
someConditionTrue && doSomething();
что в развернутом виде с if'ами:
if (someConditionTrue) {
doSomething();
}
В случае, если условия проверки единичны, то данные конструкции очень удобны (при условии, что скоп объекта однозначно заранее определен). В случае же с большим количеством условий, лучше воспользоваться if'ами — так код будет более удобочитаем.
.ps: аналогичная идеология используется в Python и Ruby.
Кстати, и стандартная консоль Python'a, и IPython не автокомлитят объекты, если они заданы явно, а не через переменную (например, просто строка — 'abc'. жмешь Таb — вылезает системный автокомплит вместо методов строки (если написать a = 'abc' и потом a. Tab — все нормально); в стандартном IDLE данная фича работает)
я в курсе (так же, по аналогии, с метро — метро был «он», поскольку — метрополитен), но, тем не менее, «он» и был «он»; а вот, говорят, что после реформы, кофе «оно» может быть (но, вероятно, не принудительно — можно и «он», и «оно»)
более того, я слышал, что после этой реформы ВУЗ можно писать теперь маленькими буквами — «вуз».
Информация мной лично не проверена, но получена от человека, который преподает в одном из универов; по его словам, там даже принялись, как оголтелые, исправлять документы с «ВУЗ» на «вуз»
> Ну, разработчиков большей части скриптов, вылазящих по этому запросу я отказываюсь называть иначе, чем мудаками-разработчики. Почему, я описывал тут. Возможно, это резко, но, думаю, вы во многом со мной согласитесь.
Относительно все это. Те, кто идут в Гугл по преведенному Вами запросу, — может, и не программисты вовсе (может, у них и не стоит задача знать JS, но скрипт готовый нужен (да и еще и устанавливается в три строчки :)); поэтому — какие они Вам «мудаки»?). Если говорить о программистах — также, может человек только серверной частью занимается, и глубоко JS знать ему и не хочется (а готовый скрипт установить вполне может) — тоже, какой он Вам «мудак»? Относительно всего этого, мнить себя гуру (на фоне вот этих персонажей) — тоже сомнительно (поскольку есть люди, действительно, очень хорошо знающие JS — на глубоком теоретическом уровне).
Поэтому, — всегда помогайте желающему знать, если знаете сами (советом, указанием на недочет и т.д.) — если он действительно стремится к знанию, — будет благодарен.
Ну а те, кто знать не желает (и при этом все вышеперечисленное к ним применимо и зовут они себя программистами), — в моей терминологии — это кодеры (программисты без собственной мысли). Хотя… и за это их винить никто не может =)
Ладно, тоже с этим закончим, а то оффтопа много уже )
Если Вы думаете, что это моя самоцель, то, уверяю Вас, — это не так. Делать мне больше нечего =) С другой стороны, — как же не отметить, что — «здесь и здесь Вы не точны»? Иначе, Вы будете нести безграмотность в массы.
> Или мне начать перечислять оглавление «bad parts» из книги Javascript: The Goods Parts?
Читал. Там высказаны личные мысли Крокфорда (со многими из них можно согласиться) по поводу того, чего бы хотелось в JS видеть (и чего там в текущей реализации нет); ничего там про то, какой JS «ужасно разболтанный язык и поддается нормальному описанию в рамках ООП» нет. К тому же, мысли эти где-то могут быть спорными.
Ладно, флудить, действительно, не будем; топик, как-никак, про виджеты.
> что ооп в изначальном смысле вовсе не ограничивалось
оно и сейчас не ограничивается; т.е. опять — понятие «рамки ООП» весьма размытое — любая реализация вправе добавлять свои оптимизации, свои идеи (если они успешные, нужные и технологически обоснованные).
> То есть, вы пишете ответ на комментарий, смысл которого не понимаете?
Демагогия.
> Там все сказано.
А причем тут Крокфорд и его реализация чего-то там? Вы утверждаете о неких рамках ООП и говорите о разболтанности JS, относительно этой сущности. Мне стало интересно, в каких конкретно моментах это коснулось JS?
.ps: кстати сказать, «ООП рамки» понятие размытое (с таким расчетом можно говорить о любом языке, что он не вписался в эти рамки).
> Этот скрипт может использоваться и один на странице.
Code reuse методом copy-paste — сами понимаете, что за «метод». Я имею в виду, если у Вас будет WidgetPanel с набором методов, а дальше появится WidgetWindow, который будет иметь лишь небольшие отличия, Вы будете все методы повторять вручную в WidgetWindow, чтобы WidgetWindow мог один использоваться на странице.
Одинаковые сущности должны куда-то выносится, и те, кто будут ими пользоваться — либо используют этот репозиторий, как примесь (либо агрегацию), либо наследуются от него.
> Видимо, корень нашего с нами непонимания состоит в том
Да нет, я прекрасно понимаю, что делает Ваш код и зачем (и вижу где-то недочеты). То, что Вы назвали «нашим с Вами непониманием» вызвано лишь тем, что Вы в первых строках статьи написали «мудаки пишут всякие тупые виджеты, а я щас покажу, как надо писать грамотный JS-код». Соответственно, у меня и подача в таком же духе — если б не было «мудаков», я бы преподнес Вам материал мягче.
> не лучше ли мне вызывать еще все методы через setTimeout
там, где надо будет делать псевдо-мультипоточность и делиться ресурсами, давая возможность выполняться другому js-коду, — лучше.
> По поводу show/hide: А зачем это городить, если будет один такой объект на странице?
старайтесь писать в общем случае, не циклясь (не хардкодя) на конкретике («Правило расширяемости: пишите с расчетом на будущее; оно наступит намного раньше, чем Вы думаете»)
> показать, хотя бы в общих чертах, как пишется правильный js-код
Да дофига недочетов у Вас, на самом деле. Вы говорите о правильном JS-коде, однако не используете при этом JS-специфичное делегирование к прототипам (а наследование на них; к примеру, может быть Panel -> Windwo -> Dialog -> и т.д. — виджеты могут наследоваться и эффективно расшаривать родительские методы, а не плодить каждый раз одинаковые методы в своем инстансе).
Данные методы описаны не оптимально. На кой черт каждый раз внутри проверять addEventListener / attachEvent, если можно сделать эту проверку единожды при инициализации библиотеки и вернуть соответствующие функции (таким образом, при навешивании событий, никаких проверок уже не будет).
> show:
> hide:
Вы там что-то о «мудаках» в статье говорили? Так вот скажите, почему у меня каждый новый dialog-объект будет иметь эти одинаковые по семантике методы? Не лучше ли их вынести в прототип и делегировать к ним? А если (в теории) будет миллион dialog-объектов? То будет миллион одинаковых функций (в то время, как могла бы быть одна).
Это последний флудовый пост в этой теме, касательно нашего с Вами разговора ;)
> по-вашему, это нормально, что преподаватель веб-технологий не может прочесть программу (лабу) на питоне?
Вполне; однако автор сказал, что читать код может, но не силен *конкретно в этой идеологии и конкретно в данных синтаксических конструкциях, которые отличаются от PHP*. К тому же, речь не о Питоне, а о Джанго.
> хотя это его область преподавания
насколько я понял, автор преподает web-технологии, и в большей мере заточенные под LAMP (хорошо это или нет — это уже другой вопрос)
> это нормально, что… не может прочесть программу (лабу) на питоне? При том, что питон один из наиболее удобочитаемых языков?
Вообще, у Питона своенравный синтаксис, и те, кто его видят впервые могут вообще не понять, в чем дело. К синтаксису Питона и Руби быстро привыкаешь, поскольку они, действительно, красивые языки. Однако, то, что Вы уже привыкли, не означает, что видящие этот синтаксис впервые, сразу разберутся, что делает та или иная конструкция. Так, например, и ассемблер кому-то привычный и очень понятный; но скажите, насколько Вы быстро прочтете асм-код и подробно расскажете, что он делает (а что? мне асм нравится и я считаю, что читать его не так и трудно, а если практикуешь каждый день — то легко)?
> Но лично я считаю, что я за свое время обучения с преподавателями, которые не знают своей предметной области, потерял кучу времени.
подобная картина может быть во многих универах; здесь надо подключать самообразование
Поэтому, дело ни в синтаксисах, ни в Питонах, ни в т.д. Повторю, мне просто Ваше высказывание показалось несправедливо-пафосным, и я обратил на это внимание (относительно флуда в теме — зря, конечно, относительно нашей с Вами беседы — думаю, нет).
Все =) На этом предлагаю закончить :) Спасибо за беседу.
Все то же самое (организовывать порождающий объект («класс») для других объектов («инстансов»), организовывать наследование, вызвать родительские перегруженные методы из объектом-потомков) вы можете делать и без этого синтаксического сахара. Единственное, для чего можно применять данные обертки — это сокращение записи наследования (подмена дефолтного прототипа конструктора на wrapper, чей прототип ссылается на прототип родительского объекта). Все. И в этих обертках реализовано именно это. Ничего другого и «магического» (а уж тем более, статических классов из Си и Java, которые являются альтернативной ООП-парадигмой — не лучше-не хуже прототипной модели) там нет.
Запись
var Zoo = Zoo || {};эквивалентна
if (window.Zoo) { // в общем случае someScope.object Zoo = Zoo; } else { Zoo = {}; }Аналогично с &&:
что в развернутом виде с if'ами:
if (someConditionTrue) { doSomething(); }В случае, если условия проверки единичны, то данные конструкции очень удобны (при условии, что скоп объекта однозначно заранее определен). В случае же с большим количеством условий, лучше воспользоваться if'ами — так код будет более удобочитаем.
.ps: аналогичная идеология используется в Python и Ruby.
Кстати, и стандартная консоль Python'a, и IPython не автокомлитят объекты, если они заданы явно, а не через переменную (например, просто строка — 'abc'. жмешь Таb — вылезает системный автокомплит вместо методов строки (если написать a = 'abc' и потом a. Tab — все нормально); в стандартном IDLE данная фича работает)
более того, я слышал, что после этой реформы ВУЗ можно писать теперь маленькими буквами — «вуз».
Информация мной лично не проверена, но получена от человека, который преподает в одном из универов; по его словам, там даже принялись, как оголтелые, исправлять документы с «ВУЗ» на «вуз»
Относительно все это. Те, кто идут в Гугл по преведенному Вами запросу, — может, и не программисты вовсе (может, у них и не стоит задача знать JS, но скрипт готовый нужен (да и еще и устанавливается в три строчки :)); поэтому — какие они Вам «мудаки»?). Если говорить о программистах — также, может человек только серверной частью занимается, и глубоко JS знать ему и не хочется (а готовый скрипт установить вполне может) — тоже, какой он Вам «мудак»? Относительно всего этого, мнить себя гуру (на фоне вот этих персонажей) — тоже сомнительно (поскольку есть люди, действительно, очень хорошо знающие JS — на глубоком теоретическом уровне).
Поэтому, — всегда помогайте желающему знать, если знаете сами (советом, указанием на недочет и т.д.) — если он действительно стремится к знанию, — будет благодарен.
Ну а те, кто знать не желает (и при этом все вышеперечисленное к ним применимо и зовут они себя программистами), — в моей терминологии — это кодеры (программисты без собственной мысли). Хотя… и за это их винить никто не может =)
Ладно, тоже с этим закончим, а то оффтопа много уже )
Если Вы думаете, что это моя самоцель, то, уверяю Вас, — это не так. Делать мне больше нечего =) С другой стороны, — как же не отметить, что — «здесь и здесь Вы не точны»? Иначе, Вы будете нести безграмотность в массы.
> Или мне начать перечислять оглавление «bad parts» из книги Javascript: The Goods Parts?
Читал. Там высказаны личные мысли Крокфорда (со многими из них можно согласиться) по поводу того, чего бы хотелось в JS видеть (и чего там в текущей реализации нет); ничего там про то, какой JS «ужасно разболтанный язык и поддается нормальному описанию в рамках ООП» нет. К тому же, мысли эти где-то могут быть спорными.
Ладно, флудить, действительно, не будем; топик, как-никак, про виджеты.
оно и сейчас не ограничивается; т.е. опять — понятие «рамки ООП» весьма размытое — любая реализация вправе добавлять свои оптимизации, свои идеи (если они успешные, нужные и технологически обоснованные).
Демагогия.
> Там все сказано.
А причем тут Крокфорд и его реализация чего-то там? Вы утверждаете о неких рамках ООП и говорите о разболтанности JS, относительно этой сущности. Мне стало интересно, в каких конкретно моментах это коснулось JS?
.ps: кстати сказать, «ООП рамки» понятие размытое (с таким расчетом можно говорить о любом языке, что он не вписался в эти рамки).
с удовольствием, если Вы просветите меня о «рамках ООП», в которые JS не вписывается, и посему становится разболтанным.
тоже теорию надо глубже изучать, чтобы не писать о «рамках ООП»
теорию надо глубже изучать ;)
> эта его нелогичность меня еще больше к нему влечет :)
логичный он, логичный.
Code reuse методом copy-paste — сами понимаете, что за «метод». Я имею в виду, если у Вас будет WidgetPanel с набором методов, а дальше появится WidgetWindow, который будет иметь лишь небольшие отличия, Вы будете все методы повторять вручную в WidgetWindow, чтобы WidgetWindow мог один использоваться на странице.
Одинаковые сущности должны куда-то выносится, и те, кто будут ими пользоваться — либо используют этот репозиторий, как примесь (либо агрегацию), либо наследуются от него.
Спасибо, «оценил» :)
Да нет, я прекрасно понимаю, что делает Ваш код и зачем (и вижу где-то недочеты). То, что Вы назвали «нашим с Вами непониманием» вызвано лишь тем, что Вы в первых строках статьи написали «мудаки пишут всякие тупые виджеты, а я щас покажу, как надо писать грамотный JS-код». Соответственно, у меня и подача в таком же духе — если б не было «мудаков», я бы преподнес Вам материал мягче.
> не лучше ли мне вызывать еще все методы через setTimeout
там, где надо будет делать псевдо-мультипоточность и делиться ресурсами, давая возможность выполняться другому js-коду, — лучше.
> По поводу show/hide: А зачем это городить, если будет один такой объект на странице?
старайтесь писать в общем случае, не циклясь (не хардкодя) на конкретике («Правило расширяемости: пишите с расчетом на будущее; оно наступит намного раньше, чем Вы думаете»)
опечатка — и наследование на них;
Да дофига недочетов у Вас, на самом деле. Вы говорите о правильном JS-коде, однако не используете при этом JS-специфичное делегирование к прототипам (а наследование на них; к примеру, может быть Panel -> Windwo -> Dialog -> и т.д. — виджеты могут наследоваться и эффективно расшаривать родительские методы, а не плодить каждый раз одинаковые методы в своем инстансе).
> removeListener
Данные методы описаны не оптимально. На кой черт каждый раз внутри проверять addEventListener / attachEvent, если можно сделать эту проверку единожды при инициализации библиотеки и вернуть соответствующие функции (таким образом, при навешивании событий, никаких проверок уже не будет).
> show:
> hide:
Вы там что-то о «мудаках» в статье говорили? Так вот скажите, почему у меня каждый новый dialog-объект будет иметь эти одинаковые по семантике методы? Не лучше ли их вынести в прототип и делегировать к ним? А если (в теории) будет миллион dialog-объектов? То будет миллион одинаковых функций (в то время, как могла бы быть одна).
> по-вашему, это нормально, что преподаватель веб-технологий не может прочесть программу (лабу) на питоне?
Вполне; однако автор сказал, что читать код может, но не силен *конкретно в этой идеологии и конкретно в данных синтаксических конструкциях, которые отличаются от PHP*. К тому же, речь не о Питоне, а о Джанго.
> хотя это его область преподавания
насколько я понял, автор преподает web-технологии, и в большей мере заточенные под LAMP (хорошо это или нет — это уже другой вопрос)
> это нормально, что… не может прочесть программу (лабу) на питоне? При том, что питон один из наиболее удобочитаемых языков?
Вообще, у Питона своенравный синтаксис, и те, кто его видят впервые могут вообще не понять, в чем дело. К синтаксису Питона и Руби быстро привыкаешь, поскольку они, действительно, красивые языки. Однако, то, что Вы уже привыкли, не означает, что видящие этот синтаксис впервые, сразу разберутся, что делает та или иная конструкция. Так, например, и ассемблер кому-то привычный и очень понятный; но скажите, насколько Вы быстро прочтете асм-код и подробно расскажете, что он делает (а что? мне асм нравится и я считаю, что читать его не так и трудно, а если практикуешь каждый день — то легко)?
> Но лично я считаю, что я за свое время обучения с преподавателями, которые не знают своей предметной области, потерял кучу времени.
подобная картина может быть во многих универах; здесь надо подключать самообразование
Поэтому, дело ни в синтаксисах, ни в Питонах, ни в т.д. Повторю, мне просто Ваше высказывание показалось несправедливо-пафосным, и я обратил на это внимание (относительно флуда в теме — зря, конечно, относительно нашей с Вами беседы — думаю, нет).
Все =) На этом предлагаю закончить :) Спасибо за беседу.