понимаю, но меру тоже надо знать. демагогически :) я не вижу конфликтов между моим и Вашим утверждениями.
вот человек попытался нам доказать, что в JS-объектах все методы должны быть наружу, прибегая ко всяким модным словам: «ООП», «наследование», «инкапсуляция» и т.д. но не раскрывая их сути. суть-то у скрытия данных и логики явно не в «экономии на слове this при доступе к свойствам в методах», правда?
или не упоминать умные слова, или вместо попыток «объективно рассмотреть достоинства и недостатки такого подхода» писать «имхо».
а кнопка минус у меня любимая, когда люди авторитетно утверждают, что можно приготовить яичницу, не разбив скорлупы ;)
я Вас правльно понял, что можно написать язык, который будет «идеологически» уметь только числа от ноля до пяти складывать — и заявить, что язык поддерживает парадигму ООП, потому что «любая реализация вправе вносить любые коррективы»?
ну конечно же, сам. я только посоветовать хочу. в ASM не надо никому доказывать, что инкапсуляцию злые дяди придумали: знай себе JMZ, да AX/BX переключай. и скорость выполнения у него фантастическая.
а может, бросить Вам эти высокоуровневые языки, для них 250мс на выполнение сложной операции является допустимой величиной, да перехойти на ASM — добьетесь экономии измеримых 225мс на счет месяца своей работы!
зачем же тогда появились высокоуровневые языки программирования, почему не зазорно использовать C++ и C#? в таком ключе не стоит думать не то, что бы об операционной системе с графическим интерфейсом, даже ASM, я так понимаю, будет злом в сравнении с машинными кодами.
зачем «план Б»? «0,5-1 секундное подвисание» в процессе работы будет при любом подходе, поскольку если надо что-то сделать, то это надо сделать, если надо сделать мильён операций — надо сделать мильён операций. а при инициализации 0,5-1 секунд не особо смутит пользователя, особенно когда страница 5-10 секунд грузится, на десктопе приложения за секунду тоже не открывается, и, если приложение открывается меньше, чем за пол-минуты, никто особо не жужжит.
> такой живой пример бага в «сокрытии реализации»
метко подмечено, но это не повод вываливать кучу купюр на асфальт, договорившись с гражданами, чтобы те пользовались только своими активами
> вставлять карту и вводить ПИН — иначе как деньги-то получить?
это не инкапсуляция?
рассмотрите пример, когда я, банкомат и деньги находятся в глобальной области видимости и кто угодно может что угодно с ними делать — без инкапсуляции. и сравните его с примером из реальной жизни, в которой пункты а и б выполняются.
какая из этих архитектур работоспособнее и адекватнее отвечает поставленным требованиям (объяснять их не надо, я надеюсь)?
1. ООП это не только хеш-объекты и оператор new;
1.1. наследование — самый главный (?), но далеко не единственный способ структурирования;
1.2. (как-то так) максимальный размер метода — семь строк;
2. Объекты представляют собою упрощенное, идеализированное описание реальных сущностей предметной области. Если соответствующие модели адекватны решаемой задаче, то работать с ними оказывается намного удобнее, чем с низкоуровневым описанием всех возможных свойств и реакций объекта. просто с вики скопировал, у Бутча было более лаконичное высказывание, как до книжки доберусь, посмотрю;
3. работа с DOM'ом — это далеко не все, на что способен JS;
3.1. работа с DOM'ом должна быть между делом, а не самоцелью;
3.2. (не совсем корректно, однако) роль сервер-сайда в проекте не обязана быть подавляющей, она может сводиться к набору сервисов; но даже если сервер-сайд играет подавляющую роль, клиент-сайд не обязан представлять из себя набор onclick'ов;
4. в споре «много кода vs гибкость/понимабельность кода» не может быть однозначного решения в любых условиях;
5. хватит считать миллисекунды, которые утекают у пользователя ради удобства разработки.
в какой-то степени, да, прав. эта степень, правда, слишком крута, чтобы находиться на одной полке с высказываниями навродя «Также к плюсам можно отнести экономию на слове this».
я вот обрисовал ситуацию с тремя объектами, а не ты, не он ответить: «да хуй с ним, с банкоматом, главное чтобы деньги.взять(100) работало» — не решаетесь. прокомментируешь?
почему не сделали? Вы сами их в статье написали и, напомню, call/apply работают аналогично new, «инстанцируя» объект, а не просто вызывая функцию. учитывая то, что иное применение у них только одно — вызвать фукнцию с нужным this, у меня не остается никаких сомнений в том, что умные дяди сделали-таки возможность для сокрытия свойств.
ну да, «не надо задумываться как они там работают» это перебор. но, опять же, от реализации зависит. ZipArchive, мне кажется, не самая тривиальная штука (не разбирался).
а песня, все-равно, другая: приятнее работать с чистым, продуманным объектом.
а зачем договариваться, когда можно нормально написать? с коллегами можно договориться, да и не денутся они не куда. только состав на предприятии меняется, я могу уйти, а коллеги останутся. я даже не упоминаю, что коллегами может быть весь мир, чтобы беседа хоть какую-то нагрузку начала нести
не все задачи можно процедурами решить. ну как, я слышал, что любой алгоритм можно на for/if реализовать, но мы больше о практике. когда надо в поле слово «поиск» убирать при фокусе, да, ООП не сдалось, но мы грим про ООП (ойжесть), а в ООП есть много традиций, выработанных дядями не злыми, а умными. почему-то против наследования никто не высказывается, а его в JS тоже нету.
объекты как хэши это одно дело, а если объектами показывают только нужные методы и даже не надо задумываться как они там работают — совсем другая песня.
> return в конструкторе вообще игнорируется
нет, только приводится к Object'у. например, вот ru.wikipedia.org/wiki/Одиночка_(шаблон_проектирования)#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.80_.D0.BD.D0.B0_Javascript
> жаль программиста, которому придется отлаживать такой код
я тоже весьма-таки удивился подходу, но его достаточно один раз понять — и дальше будет обычный дебаг, сложность которого зависит только от того, что на этом каркасе написано
> Нет, я так не считаю
Вы не представляете, как сильно я хочу увидеть в боге Javascript на популярном сайте статью на эту тему. что я вижу?
«Также к плюсам можно отнести экономию на слове this»
«Разница в 100-200мс может показаться несущественной, однако»
«Объекты с приватными свойствами сложнее в отладке»
это доказательная база? хоть бы слово про архитектуру, про то, что не надо все методы наружу показывать.
> нет никакой нужды что-то скрывать принудительно
есть, качество кода. если объект может делать do1 и do2, то зачем любому другому объекту, которому только do1 и do2 нужны, иметь возможность смотреть doWith и вызвать validateWith?
насчет Ваших познаний JS мне ничего не известно. а что, не должно бы?
вот человек попытался нам доказать, что в JS-объектах все методы должны быть наружу, прибегая ко всяким модным словам: «ООП», «наследование», «инкапсуляция» и т.д. но не раскрывая их сути. суть-то у скрытия данных и логики явно не в «экономии на слове this при доступе к свойствам в методах», правда?
или не упоминать умные слова, или вместо попыток «объективно рассмотреть достоинства и недостатки такого подхода» писать «имхо».
а кнопка минус у меня любимая, когда люди авторитетно утверждают, что можно приготовить яичницу, не разбив скорлупы ;)
метко подмечено, но это не повод вываливать кучу купюр на асфальт, договорившись с гражданами, чтобы те пользовались только своими активами
> вставлять карту и вводить ПИН — иначе как деньги-то получить?
это не инкапсуляция?
рассмотрите пример, когда я, банкомат и деньги находятся в глобальной области видимости и кто угодно может что угодно с ними делать — без инкапсуляции. и сравните его с примером из реальной жизни, в которой пункты а и б выполняются.
какая из этих архитектур работоспособнее и адекватнее отвечает поставленным требованиям (объяснять их не надо, я надеюсь)?
любой!? нужна или, может, сразу необходима?
1.1. наследование — самый главный (?), но далеко не единственный способ структурирования;
1.2. (как-то так) максимальный размер метода — семь строк;
2. Объекты представляют собою упрощенное, идеализированное описание реальных сущностей предметной области. Если соответствующие модели адекватны решаемой задаче, то работать с ними оказывается намного удобнее, чем с низкоуровневым описанием всех возможных свойств и реакций объекта. просто с вики скопировал, у Бутча было более лаконичное высказывание, как до книжки доберусь, посмотрю;
3. работа с DOM'ом — это далеко не все, на что способен JS;
3.1. работа с DOM'ом должна быть между делом, а не самоцелью;
3.2. (не совсем корректно, однако) роль сервер-сайда в проекте не обязана быть подавляющей, она может сводиться к набору сервисов; но даже если сервер-сайд играет подавляющую роль, клиент-сайд не обязан представлять из себя набор onclick'ов;
4. в споре «много кода vs гибкость/понимабельность кода» не может быть однозначного решения в любых условиях;
5. хватит считать миллисекунды, которые утекают у пользователя ради удобства разработки.
я вот обрисовал ситуацию с тремя объектами, а не ты, не он ответить: «да хуй с ним, с банкоматом, главное чтобы деньги.взять(100) работало» — не решаетесь. прокомментируешь?
имелась ввиду возможножсть сохранить уникальность локальный переменных при «наследовании»:
function Q() { var a = 5; this.change = function() { a = 10; } this.alert = function() { alert(a); }; } function W() { Q.call(this); } w1 = new W(); w1.change(); w2 = new W(); w1.alert(); // 10 w2.alert(); // 5> new делает еще кое-что за нас
имелось ввиду, что вместо (f.apply(o, arguments), o) можно было бы просто написать new o(x)?
ну да, «не надо задумываться как они там работают» это перебор. но, опять же, от реализации зависит. ZipArchive, мне кажется, не самая тривиальная штука (не разбирался).
а песня, все-равно, другая: приятнее работать с чистым, продуманным объектом.
не все задачи можно процедурами решить. ну как, я слышал, что любой алгоритм можно на for/if реализовать, но мы больше о практике. когда надо в поле слово «поиск» убирать при фокусе, да, ООП не сдалось, но мы грим про ООП (ойжесть), а в ООП есть много традиций, выработанных дядями не злыми, а умными. почему-то против наследования никто не высказывается, а его в JS тоже нету.
объекты как хэши это одно дело, а если объектами показывают только нужные методы и даже не надо задумываться как они там работают — совсем другая песня.
нет, только приводится к Object'у. например, вот
ru.wikipedia.org/wiki/Одиночка_(шаблон_проектирования)#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.80_.D0.BD.D0.B0_Javascript
> жаль программиста, которому придется отлаживать такой код
я тоже весьма-таки удивился подходу, но его достаточно один раз понять — и дальше будет обычный дебаг, сложность которого зависит только от того, что на этом каркасе написано
ненавижу опечатки
Вы не представляете, как сильно я хочу увидеть в боге Javascript на популярном сайте статью на эту тему. что я вижу?
«Также к плюсам можно отнести экономию на слове this»
«Разница в 100-200мс может показаться несущественной, однако»
«Объекты с приватными свойствами сложнее в отладке»
это доказательная база? хоть бы слово про архитектуру, про то, что не надо все методы наружу показывать.
> нет никакой нужды что-то скрывать принудительно
есть, качество кода. если объект может делать do1 и do2, то зачем любому другому объекту, которому только do1 и do2 нужны, иметь возможность смотреть doWith и вызвать validateWith?