Но он должен быть реализован, так? То есть вместо Backbone.Component вам нужен какой-то другой инструмент, выполняющий эту функцию по-своему. А мне например в моём проекте этот инструмент не нужен, я не хочу его использовать.
Хорошо, когда есть альтернатива, правда?
Если хотите, это как раз альтернатива бесконечным вложенным вьюхам. Я видел проекты, в которых степень вложенности могла достигать 5-8 уровней, это абсолютно нечитабельный код.
Обычно по-настоящему требуется всего три уровня вложенности:
1) общий лэйаут
2) основные области страницы (меню, контент и т.д.)
3) повторяющиеся элементы
Лэйаут не обязательно должен быть вьюхой, т.к. собственной отрисовки у него по сути нет. Для повторяющихся элементов я предлагаю использовать компоненты. А для view оставить только области страницы.
Я их вообще почти не использую, если вам это так интересно. Мне не нравится подход Marionette и подобных. Потом, это ведь всего лишь один частный подход, который никак не реализован на уровне самого Backbone.
Нет, всё это как раз обдумывалось.
1) Смысл «загаживать» view — удобство в использовании. Мне лично намного приятнее написать в шаблонах вот такой простой вызов без лишних инициализаций/ручных добавлений методов и т.д. Это сокращает объём кода. И потом, почему собственно не view — он разве не для этого предназначен?
2) По поводу использования отдельного view — недостаток всё тот же, ручное прописывание лишнего кода. Вам же надо сначала проинициализировать его (прописав это в render), потом деинициализировать, и так на каждый элемент. Самим отслеживать момент деинициализации, и не дай бог ошибётесь, будет мемори лик, который потом замучаетесь искать.
3) > Вам и так сообщать об удалении вызвав ветод remove
Это только один из подходов. Можно не вызывать remove, а сохранять view и всю его DOM-структуру в памяти, чтобы ускорить отрисовку при следующем вызове.
4) > слушать кучу сообщений от браузера без реальной нужды не вижу
Ну тут на вкус и цвет. Я стараюсь не писать код, который можно не писать — из этого всегда и исхожу. Этот плагин сокращает количество кода в приложении, вот и вся «реальная нужда». «Куча» сообщений не такая большая, посмотрите, как реализован MutationObserver. Если вы перерисовали view целиком, присвоив родительсокму элементу новый HTML, у вас вызовется одно сообщение в MutationObserver.
А как же this? Если речь о внутренних методах класса, то его придётся передавать отдельным аргументом, лишний код и неудобно.
А чем второй случай не устраивает?
Ну всё тем же — лишним кодом. В джаваскрипте или руби этот врап не нужен, просто обращаетесь к любому методу по имени.
Вы объясните зачем вам это может понадобиться
Хорошо, есть веб-приложение с роутами (привязка к url), есть контроллер, у которого на роуты замаплены методы (/something/show -> SomethingController.show). Это элементарный случай, бывают более сложные, но реже. Напишите хотя бы изящное решение для этого.
Ну то есть в первом случае это не метод класса (что в мап можно запихать по имени — и так понятно, с этим и в плюсах проблем нет), а во втором то извращение, котороые вы привели? Ну как бы не впечатлило оба раза.
Ну вопрос-то не в этом. Если у вас уже есть написанный код (a.myMethod), значит имя метода вам известно, тут и правда смысла нет пользоваться (если известно имя метода, то известно и есть он или нет).
Если же вы про совсем крайний случай, то в чем преимущество у a.«method_$name»(b) над a(s«method_$name»)(b)? В одном символе?
Не понял этой записи. Давайте на джаваскрипте, его все знают. Условно вот такой вызов: a["method_" + name](b), у него есть аналог в Scala? Вот это я хочу понять, потому что это наверное самая частоиспользуемая мной конструкция из метапрограммирования.
Ну Ruby и Python тоже сильно популярнее любого варианта с типизированным языком. C++ иногда используют как вспомогательный из-за производительности (но сайты целиком на плюсах — это большая редкость), Java свою нишу занимает, но в целом динамические языки явно доминируют.
Ну вы про DSL и всё такое прочее? Да, это понятно, но я о другом, я-то как раз про рантайм. То, что можно менять код во время выполнения (ну например по результату выполнения запроса из базы данных, но вообще много сценариев) — это одна из любимых моих фич динамических языков. Вот её я часто использую, а DSL — ну сильно реже.
Зато в пыхе я должено постоянно писать МИЛЛИОНЫ ====== чтоб уж ТОЧНО быть уверенным, что там false, а не 0.
Ну вы нашли с чем сравнивать. Если уж приводите Скалу, то и сравнивайте с чем-то более приличным.
Что там кстати с метапрограммированием? Как насчёт вызова метода по строке с именем или добавления метода в существующий объект? Для общего развития спрашиваю, без подколов, т.к. Скалу не знаю.
И да, так себе удобство прямо скажем. Структуру класса IDE и так подсвечивают, а прыгать по двум файлам — несколько сомнительное удовольствие и при чтении-то, а уж при кодинге особенно.
Никто не запрещает, но объявленные в хедере функции компилятор воспринимает, как кандидаты в инлайны. Как там в итоге компилятор отработает, точно сказать конечно нельзя, но это очень жирная подсказка со стороны разработчика, так что это как минимум не то же самое, что писать в двух файлах.
Вот не знаю, по моим наблюдениям время на дебаг у меня как раз сократилось после перехода на динамические языки. Но допускаю, что зависит от специфики задач.
Qt — это прекрасно конечно (без шуток), но от необходимости описывать один класс в двух файлах он как-то избавляет? «Больше строчек» — это медицинский факт. А хорошие фреймворки и под другие языки есть.
А я ведь не просто так «того же мнения» придерживаюсь. Писал же я на C++, много писал, всё знаю и проходил. Что на C++ кодить дольше, чем на Ruby — это ну настолько аксиома для меня, что даже не знаю. Ну не пробовали вы всерьёз писать на динамических языках, сами же признались выше, тогда о чём разговор-то?
Ну то есть это нормально платить программистам на C++ меньшие зарплаты, чтобы выкроить дополнительное время для разработки приложения? Ну ок, нормально так нормально, вам как программисту на C++ виднее конечно.
Хорошо, когда есть альтернатива, правда?
Обычно по-настоящему требуется всего три уровня вложенности:
1) общий лэйаут
2) основные области страницы (меню, контент и т.д.)
3) повторяющиеся элементы
Лэйаут не обязательно должен быть вьюхой, т.к. собственной отрисовки у него по сути нет. Для повторяющихся элементов я предлагаю использовать компоненты. А для view оставить только области страницы.
1) Смысл «загаживать» view — удобство в использовании. Мне лично намного приятнее написать в шаблонах вот такой простой вызов без лишних инициализаций/ручных добавлений методов и т.д. Это сокращает объём кода. И потом, почему собственно не view — он разве не для этого предназначен?
2) По поводу использования отдельного view — недостаток всё тот же, ручное прописывание лишнего кода. Вам же надо сначала проинициализировать его (прописав это в render), потом деинициализировать, и так на каждый элемент. Самим отслеживать момент деинициализации, и не дай бог ошибётесь, будет мемори лик, который потом замучаетесь искать.
3) > Вам и так сообщать об удалении вызвав ветод remove
Это только один из подходов. Можно не вызывать remove, а сохранять view и всю его DOM-структуру в памяти, чтобы ускорить отрисовку при следующем вызове.
4) > слушать кучу сообщений от браузера без реальной нужды не вижу
Ну тут на вкус и цвет. Я стараюсь не писать код, который можно не писать — из этого всегда и исхожу. Этот плагин сокращает количество кода в приложении, вот и вся «реальная нужда». «Куча» сообщений не такая большая, посмотрите, как реализован MutationObserver. Если вы перерисовали view целиком, присвоив родительсокму элементу новый HTML, у вас вызовется одно сообщение в MutationObserver.
Хорошо, принято. Понял, что можно.
Ну нет же. Если рассматривать целиком объявление и вызов, то или не лаконично или не то.
А как же this? Если речь о внутренних методах класса, то его придётся передавать отдельным аргументом, лишний код и неудобно.
Ну всё тем же — лишним кодом. В джаваскрипте или руби этот врап не нужен, просто обращаетесь к любому методу по имени.
Хорошо, есть веб-приложение с роутами (привязка к url), есть контроллер, у которого на роуты замаплены методы (/something/show -> SomethingController.show). Это элементарный случай, бывают более сложные, но реже. Напишите хотя бы изящное решение для этого.
Ну вопрос-то не в этом. Если у вас уже есть написанный код (a.myMethod), значит имя метода вам известно, тут и правда смысла нет пользоваться (если известно имя метода, то известно и есть он или нет).
Не понял этой записи. Давайте на джаваскрипте, его все знают. Условно вот такой вызов:
a["method_" + name](b), у него есть аналог в Scala? Вот это я хочу понять, потому что это наверное самая частоиспользуемая мной конструкция из метапрограммирования.Ну вы про DSL и всё такое прочее? Да, это понятно, но я о другом, я-то как раз про рантайм. То, что можно менять код во время выполнения (ну например по результату выполнения запроса из базы данных, но вообще много сценариев) — это одна из любимых моих фич динамических языков. Вот её я часто использую, а DSL — ну сильно реже.
Ну вы нашли с чем сравнивать. Если уж приводите Скалу, то и сравнивайте с чем-то более приличным.
Что там кстати с метапрограммированием? Как насчёт вызова метода по строке с именем или добавления метода в существующий объект? Для общего развития спрашиваю, без подколов, т.к. Скалу не знаю.
То есть по году на каждый или в какой пропорции? Просто если из этих 3-х лет 2.5 — PHP, то это скажем несколько отдельный разговор.