Здравствуйте, Ночной Смотрящий, Вы писали:
A>>Нет, я так не считаю, но пока что тут никто про объективные недостатки JS и не говорил. НС>Разве?
Точно тебе говорю.
НС>Это разве хамство? А теперь сравни со своим:
Зачем мне сравнивать? Я тоже могу сказать, что не хамил.
НС>Если непонятно, в чем разница: в моих цитатах нет упоминания личности собеседника, в отличие от.
Здравствуйте, Mamut, Вы писали:
D>>Один вопрос. Как мне на JS сделать иерархию классов с передачей параметров конструктора базовому классу?
M>Можно посмотреть, как это сделано в ExtJS, например. Сейчас просто навскидку не скажу
Не знаю за ExtJS, но в yui, к примеру, это сделано через задницу. Нормального способа не существует, а агрегация — не всегда решение (мне лично что-то сложное на JS нужно только когда я дублирую серверный код, скажем те же формы для client-only валидации и прочей динамики).
Здравствуйте, Mamut, Вы писали:
НС>>В сочетании с доопределенными в пользовательском коде свойствами и методами — нечасто.
M>Переведи эту фразу на русский, плиз.
А что тут непонятного? Чтобы прототипное ООП действительно им было, нужен полиморфизм по методам, которые динамически добавляются в пользовательском коде.
M>Ну и раз ты сам заговорил об extension methods... Вот вы с Пацаком продолжаете твердить, что, мол, в JS должен быть ООП
Ложь. Я такого никогда не утверждал.
M>Я задавал этот вопрос уже раза три, и ни разу никто так на него и не ответил: какую реализацию ООП возьмем?
В каком смысле какую? Можно поконкретнее?
M>Вот, например, extension methods из C#. В prototype-based OO функциональность, ими предоставляемая, существует, что говорится, «искаропки». Собственно, из-за определения prototype-based OO.
Здравствуйте, anonymous, Вы писали:
A>>>Нет, я так не считаю, но пока что тут никто про объективные недостатки JS и не говорил. НС>>Разве?
A>Точно тебе говорю.
А мне, показалось что, к примеру, обсуждали ситуацию, когда несколько дней было потеряно из-за пропущенного var. По мне так такое для современного ЯП — epic fail и такой язык хорошим называться не может.
НС>>Если непонятно, в чем разница: в моих цитатах нет упоминания личности собеседника, в отличие от. A>Обезличенное хамство не менее хамовато.
НС>>>В сочетании с доопределенными в пользовательском коде свойствами и методами — нечасто.
M>>Переведи эту фразу на русский, плиз.
НС>А что тут непонятного? Чтобы прототипное ООП действительно им было, нужен полиморфизм по методам, которые динамически добавляются в пользовательском коде.
У тебя странное понимание или ООП или полиморфизма, или и того и другого вместе
(специально для тебя, а то у тебя опять странные ассоциации начнутся: тэг java ниже использован только потому, что на RSDN нет тэга для подсветки javascript'а)
// вместо Object может быть любой другой объект, тут просто иллюстрацияvar a = new Object();
// типа extension methods
// функциональность доступна из коробки в любом прототипном языке по определению
// Более того, это ничем не отличается от банального добавления нового метода в определение класса
// Единственная разница — добавление может происходить динамически
Object.protype.new_method = function(){...};
// Полиморфизм никуда не делся
// то, что он выглядит/реализован по-другому
// не значит, что его нет или он редко используется
// Вот он, во всей красе:
// у объекта а поменялся класс
// теперь он — наследник базового класса, с новым методом
a.another_method = function(){ ... };
// Разовьем идею, дадим ей черты
// - с одной стороны, нужные, если нам нужна новая функциональность на основе базового класса
// чаще, чем один раз
// - с другой стороны, более привычная всяким зашоренным мозгам:
// примеры из ExtJS, используемые функции приводить не буду, и так все понятно должно быть
// создали объект класса Ext.Panel
// пердположим, что у Panel есть метод renderTo();var panel = new Ext.Panel({...});
// создали новый класс-наследник Ext.Panel, отличающийся от родителя одним новым методомvar MyCustomPanel = Ext.extend(Ext.Panel, {
new_method: function(){...};
});
// создаем объект класса MyCustomPanelvar custom_panel = new MyCustomPanel({...})
panel.renderTo(...); // ура, сработало
panel.new_method(); // ошибка, потому что нетути такого в базовом классе
custom_panel.renderTo(); // ура, сработало, потому что наследование и полиморфизм
custom_panel.new_method(); // ура, сработало, по тем же причинам
Я привел список из трех пунктов, которые ты решил не цитировать, и на него не отвечать. Куда ж еще конкретнее?
M>>Вот, например, extension methods из C#. В prototype-based OO функциональность, ими предоставляемая, существует, что говорится, «искаропки». Собственно, из-за определения prototype-based OO.
НС>extension methods это не ООП.
Без разницы. Какую именно реализацию берем, и почему?
D>>>Один вопрос. Как мне на JS сделать иерархию классов с передачей параметров конструктора базовому классу?
M>>Можно посмотреть, как это сделано в ExtJS, например. Сейчас просто навскидку не скажу
D>Не знаю за ExtJS, но в yui, к примеру, это сделано через задницу. Нормального способа не существует, а агрегация — не всегда решение (мне лично что-то сложное на JS нужно только когда я дублирую серверный код, скажем те же формы для client-only валидации и прочей динамики).
Здравствуйте, Mamut, Вы писали:
A>>>За 5 минут чужие скрипты не дорабатывают, ни на одном из новых для программиста языков. П>>OK, один день раз в полгода — и? Что это меняет-то? M>Если это — скрипт на Питоне, это что-то изменит? Если да, то что? А если на Ruby?
Изменит.
С JS очень часто приходится "по-чуть-чуть" взаимодействовать людям, пишущим на C# или Java. Т.е. основной для них язык с "традиционной" схемой наследования. Пишут серверную часть веб прилады и время-от-времени, но редко, требуется сделать немного кода на стороне клиента. И вот тут начинается ломка. На первый взгляд язык похож на C#/Java, даже названием, а потом вдруг начинаются проблемы. Причем он не воспринимается как серьезный язык данным программистом. Потому что для него основная программа — это серверный код. А эти js-дополнения просто вспомогательные расширения. Человеку как-то не приходит в голову, что эту фигню надо тоже тщательно заранее изучить.
Случаи, когда C#\Java программисту приходится так же часто и понемногу взаимодействовать с Python/Ruby — крайне редки. Потому и массовых вопросов не возникает.
З.Ы.
Я не говорю, что поведение данных программистов правильное, но оно понятно, и его не получится изменить просто горячим призывом "а давайте вы все резко выучите JS".
Здравствуйте, fmiracle, Вы писали:
F>С JS очень часто приходится "по-чуть-чуть" взаимодействовать людям, пишущим на C# или Java. Т.е. основной для них язык с "традиционной" схемой наследования. Пишут серверную часть веб прилады и время-от-времени, но редко, требуется сделать немного кода на стороне клиента. И вот тут начинается ломка.
Ему это уже раз десять говорили. Без толку — человек принципиально не понимает разницы между "писать ежедневно" и "пописывать иногда". Либо (более вероятно имхо) делает вид, что не понимает этой разницы.
A>>>>За 5 минут чужие скрипты не дорабатывают, ни на одном из новых для программиста языков. П>>>OK, один день раз в полгода — и? Что это меняет-то? M>>Если это — скрипт на Питоне, это что-то изменит? Если да, то что? А если на Ruby?
F>Изменит.
F>С JS очень часто приходится "по-чуть-чуть" взаимодействовать людям, пишущим на C# или Java. Т.е. основной для них язык с "традиционной" схемой наследования. Пишут серверную часть веб прилады и время-от-времени, но редко, требуется сделать немного кода на стороне клиента. И вот тут начинается ломка. На первый взгляд язык похож на C#/Java, даже названием, а потом вдруг начинаются проблемы. Причем он не воспринимается как серьезный язык данным программистом. Потому что для него основная программа — это серверный код. А эти js-дополнения просто вспомогательные расширения. Человеку как-то не приходит в голову, что эту фигню надо тоже тщательно заранее изучить.
Опять. В одном предложении «по чуть-чуть» и «тщательно изучить». Вы уже определитесь, что вы делаете — по чуть чуть или все жа тщательно. Если по чуть-чуть, то ничего особо странного в JS нет.
F>>С JS очень часто приходится "по-чуть-чуть" взаимодействовать людям, пишущим на C# или Java. Т.е. основной для них язык с "традиционной" схемой наследования. Пишут серверную часть веб прилады и время-от-времени, но редко, требуется сделать немного кода на стороне клиента. И вот тут начинается ломка.
П>Ему это уже раз десять говорили. Без толку — человек принципиально не понимает разницы между "писать ежедневно" и "пописывать иногда". Либо (более вероятно имхо) делает вид, что не понимает этой разницы.
Тебе уже тоже 10 паз говорили, что при «пописывать иногда» всех твоих страхов никогда не видно.
Здравствуйте, Mamut, Вы писали:
M>Опять. В одном предложении «по чуть-чуть» и «тщательно изучить». Вы уже определитесь, что вы делаете — по чуть чуть или все жа тщательно. Если по чуть-чуть, то ничего особо странного в JS нет.
Это ты определись — на что тебе жалуются. На то, что в JS "неправильные классы" или на то, что "в нем вааще-вааще ничего невозможно сделать".
Если говорить вкратце, то проблема в том, что простые задачи делаются легко и, главное, почти как в основном языке, а когда вдруг хочется сделать что-то чуть более сложное, то вдруг оказывается, что все совсем иначе. Но нет необходимости разбираться в этом — поскольку возникающую задачу обычно можно решить и более тупым методом (типа копипаста), что и делают. При этом считая, что "язык какой-то странный и неправильный". То есть задачи достаточны, чтобы осознать, что язык какой-то не такой, но недостаточны, чтобы возникла реальная необходимость его изучить и рационально использовать.
Я обычно курирую приходящую молодежь, потому ситуация мне вполне знакома. Человеку надо сделать простую валидацию, например. Проверить значение в одном поле — он моментально пишет функцию, которая находит текст, проверяет его значение, ну все номрально в общем. Заодно еще раз убеждается, Что JS — это очень похоже на шарп, только в браузере.
Потом у него возникает необходимость чуть более сложной проверки, например проверка суммы чисел в группе полей, причем в нескольких местах сайта, и посмотрев на задачу он видит два варианта:
1. накопипастить несколько похожих методов с мелкими различиями
2. сделать небольшой класс, инкапсулирующий часть данных, и несколько мелких наследников, которые покроют все эти случаи
Человек по молодости и из-за ограниченного кругозора уверен, что JS — это почти как шарп. Он обещает начальнику, что тут фигня вопрос, сделает к вечеру. Начинает делать, и видит что классов нет. Начинает разбирать, и видит какие-то прототипы, незнакомые ему. Но дальше разбирать некогда — уже обещал ведь, что к вечеру будет все. Откатывается на вариант 1, по-быстрому копипастит клоны методов и материт js, "что все в нем неправильно".
И тут бы ему изучить js тщательно, ан нет — задача решена и так, все работает, а следующее рандеву с js как-то пока не предвитися (оно будет, спустя какое-то время, но не сейчас).
В результате у человека остается:
1. умение работать с js на базовом уровне, достаточном для решения всех его практических задач (хотя и зачастую весьма неудобным образом). Что убирает необходимость в его дальнейшем изучении.
2. впечатление, что язык ограничен именно этим базовым уровнем, а для более сложных вещей, используется какая-то черная магия и непонятные костыли.
Здравствуйте, Mamut, Вы писали:
M>Тебе уже тоже 10 паз говорили, что при «пописывать иногда» всех твоих страхов никогда не видно.
И каждый раз это утверждение заканчивалось словами "...надо только изучить и заюзать костыль библиотечку под названием XXXXX". Тогда как речь, напоминаю, идет не о библиотеках, а об языке. Который в чистом виде для такого режима не удобен ни разу.
Лично мне, благодаря некоторому общему опыту, прототипы и классы в js не вызывают проблем. Но я бы тоже предпочел, чтобы язык в браузере был ближе к языку на сервере, поскольку переключение парадигмы — не очень-то удобно. Плюс необходимость в более глубоких концепциях js возникает настолько редко, что детали забываются, и когда таки возникает необходимость что-то такое сделать, зачастую приходится лезть за справочником...
M>>Опять. В одном предложении «по чуть-чуть» и «тщательно изучить». Вы уже определитесь, что вы делаете — по чуть чуть или все жа тщательно. Если по чуть-чуть, то ничего особо странного в JS нет.
F>Это ты определись — на что тебе жалуются. На то, что в JS "неправильные классы" или на то, что "в нем вааще-вааще ничего невозможно сделать".
Вот я и пытаюсь. Начинаещь подходить со стороны «новый инструмент надо изучать», начинается нытье про «раз в полгода» и сказки про страшные делегаты
как тут же начинается, цитирую тебя в этом же сообщении: к нам приходят на работу (!) люди, чья задача (!) писать какую-то функциональность на JS.
Но, блин, JS виноват в том, что для изучения инструмента, от которого зависит решение определенной задачи считается нормальным подход «И тут бы ему изучить js тщательно, ан нет — задача решена и так, все работает»
При том, что если бы такой подход был применен к любому другому инструменту на той же работе, человек вылетел бы на улицу на второй же день
Так что вы давайте определяйтесь, что такое у вас «чуть-чуть» и «раз в полгода»
Потому что код на js, занимающийся валидацией данных — без прототипов! — мало чем будет отличаться от аналогичного кода на том же C#.
Ах, да. Там не будет слова class, а будет, наверное, слово function
F>В результате у человека остается: F>1. умение работать с js на базовом уровне, достаточном для решения всех его практических задач (хотя и зачастую весьма неудобным образом). Что убирает необходимость в его дальнейшем изучении. F>2. впечатление, что язык ограничен именно этим базовым уровнем, а для более сложных вещей, используется какая-то черная магия и непонятные костыли.
Угу. И в этом виноват — внезапно — язык, а не человек. Нуну.
M>>Тебе уже тоже 10 паз говорили, что при «пописывать иногда» всех твоих страхов никогда не видно.
П>И каждый раз это утверждение заканчивалось словами "...надо только изучить и заюзать костыль библиотечку под названием XXXXX". Тогда как речь, напоминаю, идет не о библиотеках, а об языке. Который в чистом виде для такого режима не удобен ни разу.
Ага, известный аргумент. Как только JS — надо обязательно писать только на голом JS. Как только другой язык — бури люую библиотеку вплоть до use System.Windows.Forms.
Но дадада. Одинаковые подходы ко всем языкам и инструментам — это для слабаков.
Здравствуйте, Mamut, Вы писали:
M>Ага, известный аргумент. Как только JS — надо обязательно писать только на голом JS. Как только другой язык — бури люую библиотеку вплоть до use System.Windows.Forms.
Ога, именно так. Потому что на любом другом языке момент "используй библиотеку" у человека наступает обычно после того, как он более-менее сносно поймет сам язык. А не вместо этого, как это предлагаешь ты.
M>Но дадада. Одинаковые подходы ко всем языкам и инструментам — это для слабаков.
Вот интересно, сколько еще человек и сколько раз тебе должны тут написать о том, что в случае js подход изначально кардинально отличается от повседневно используемых языков, чтобы ты перестал делать вид, что ты этого не понимаешь? Вот выше fmiracle уж совсем разжевал и чуть ли не в рот положил — ан нет, никакого эффекта, продолжаешь всё тот же бессмысленный плач Ярославны. Самому-то не надоело еще?
M>>Ага, известный аргумент. Как только JS — надо обязательно писать только на голом JS. Как только другой язык — бури люую библиотеку вплоть до use System.Windows.Forms.
П>Ога, именно так. Потому что на любом другом языке момент "используй библиотеку" у человека наступает обычно после того, как он более-менее сносно поймет сам язык. А не вместо этого, как это предлагаешь ты.
Для того, чтобы сносно понять JS нужно полдня. Ладно, один.
M>>Но дадада. Одинаковые подходы ко всем языкам и инструментам — это для слабаков.
П>Вот интересно, сколько еще человек и сколько раз тебе должны тут написать о том, что в случае js подход изначально кардинально отличается от повседневно используемых языков,
Чем он кардинально отличается? Можешь начать со своего плача Ярославны про делегаты.листенеры
.
П>чтобы ты перестал делать вид, что ты этого не понимаешь? Вот выше fmiracle уж совсем разжевал и чуть ли не в рот положил — ан нет, никакого эффекта, продолжаешь всё тот же бессмысленный плач Ярославны. Самому-то не надоело еще?
Нихрена он не разжевал. От него ровно такое же нытье, как и от тебя. Про что я написал тут
F>P.S. F>Долго писал, забыл добавить.
F>Лично мне, благодаря некоторому общему опыту, прототипы и классы в js не вызывают проблем. Но я бы тоже предпочел, чтобы язык в браузере был ближе к языку на сервере, поскольку переключение парадигмы — не очень-то удобно. Плюс необходимость в более глубоких концепциях js возникает настолько редко, что детали забываются, и когда таки возникает необходимость что-то такое сделать, зачастую приходится лезть за справочником...
Ну блин, аналогично для любого языка программирования.
Был бы питон, ныли бы про отступы, self в декларациях методов и крявый синтаксис лямбд. ПОтому что это все отличается от Java/C#/C++/бог знает, что
Был бы руби, ныли бы про блоки, миксины, unless'ы, непонятную конструкцию catch .. do и т.п.
Был бы C#, программисты Java/C++ ныли бы про делегаты, лямбды и бог знает, что еще
Была бы Java, C# ныл бы про отсутсвие делегатов, ляьмд, C++ ныл бы про отсутсвие галонов и бог знает чего еще
И ты ды и ты пы.
Но мне упорно пытаются рассказать сказки, что это язык виноват в том, что программисты не хотят изучать инструмент, с которым они работают, и что любой другой язык был бы лучше. Агага. Вот прямощаз
F>P.S. F>Долго писал, забыл добавить.
F>Лично мне, благодаря некоторому общему опыту, прототипы и классы в js не вызывают проблем. Но я бы тоже предпочел, чтобы язык в браузере был ближе к языку на сервере, поскольку переключение парадигмы — не очень-то удобно. Плюс необходимость в более глубоких концепциях js возникает настолько редко, что детали забываются, и когда таки возникает необходимость что-то такое сделать, зачастую приходится лезть за справочником...
Совсем забыл. Я бы тоже был совсем не против иметь одинаковый язык на сервере и в браузере. Только вот языков на сервере — легион
