Теперь давайте какие реальные плюсы у т.н. декларативного? Букв меньше не стало. Совокупная сложность кода не понизилась — все равно в конвертере есть проверка if и выбор цвета. В XML-е писать не удобнее, но даже не в этом суть.
Только вера в то, что декларативно типа круче?
Ну ОК, вы скажите что ковертор можно будет задействовать в другом месте. Но! Что мешает мне вынести:
if (businessObject.Date.IsOdd)
DateTextBox.Background = Color.Red;
— в отдельный метод и просто его вызывать? Вам для конвертора придется целый класс содавать а мне — только метод.
Подозреваю что начнут приводить преимущества т.н. двустороннего связывания и обработки событий изменения данных. У меня есть что ответить на это, но подожду пока скажут.
Получается, что никакого реального преимущества, кроме хайпа, нет
Здравствуйте, Shmj, Вы писали:
S>Получается, что никакого реального преимущества, кроме хайпа, нет :xz:
Ни так, ни эдак делать не нужно. И декларативное vs. императивное тут ни при чём.
Конвертер не нужен. Потому что ViewModel — это и есть конвертер на стероидах. Должна быть привязка к свойству во вью-модели того же типа, что требуется для GUI. А уж внутри этого свойства мапь из низлежащих данных хоть императивно, хоть декларативно. На внешнем уровне всё останется декларативным.
Здравствуйте, Shmj, Вы писали:
S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?
Часто упрощает. Классический пример: соотношение размеров графических элементов, простые анимации и т.п.
В С++ и Qt есть оба подхода: QML и QWidgets. Многое на QML проще.
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
S>>Почему все верят, что декларативный подход рулит и на порядок упрощает работу? S>В С++ и Qt есть оба подхода: QML и QWidgets. Многое на QML проще.
Действительно, некоторые простые примеры на QML выглядят проще. Но, не совсем понятно, как можно называть QML-подход декларативным. Как там насчет таблиц и деревьев? А деревьев в таблицах, сожержащих таблицы? Не нужно, да?
Re: Связывание форм (GUI) с данными: императивно vs декларативно
S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу? S>Вот, давайте на примере.
Возьмите пример посложнее. ГУИ для списка, содержащего деревья разных типов, содержащие списки разных типов. Используйте темплейты для данных. Готово.
Что нужно сделать для создания ГУИ императивно? Даже подумать страшно. Определенные императивные технологии, и некоторые причисляющие себя к "декларативным", такого в принципе не поддерживают.
Вот это и есть порядок реального преимущества.
Re[3]: Связывание форм (GUI) с данными: императивно vs декларативно
Здравствуйте, Владимир35, Вы писали:
В>Действительно, некоторые простые примеры на QML выглядят проще. Но, не совсем понятно, как можно называть QML-подход декларативным. Как там насчет таблиц и деревьев? А деревьев в таблицах, сожержащих таблицы? Не нужно, да?
А никто и не говорил, что все задачи можно решить чисто декларативным подходом, в отличии от императивного. Очевидно, что кто-то должен реализовать эту подкапотную магию, для всех случаев это невозможно
Re: Связывание форм (GUI) с данными: императивно vs декларативно
S>Теперь давайте какие реальные плюсы у т.н. декларативного? Букв меньше не стало. Совокупная сложность кода не понизилась — все равно в конвертере есть проверка if и выбор цвета. В XML-е писать не удобнее, но даже не в этом суть.
Потому что ты не зе знаешь никаких других подходов, кроме XAML'а, и делаешь далеко идущие выводы. Например, SwiftUI тоже декларативный, сильно короче XAML'а и короче аналогичного декларативного бкода, и наглядно показывает удобство деклартивного кода и прозрачного связывания данных даже на простых примерах, например тут: https://developer.apple.com/tutorials/swiftui/creating-and-combining-views UI просто становится комбинацией вложенных структур, которые можно как угодно менять и вкладывать друг в друга.
Здравствуйте, Shmj, Вы писали:
S>Теперь давайте какие реальные плюсы у т.н. декларативного? Букв меньше не стало. Совокупная сложность кода не понизилась — все равно в конвертере есть проверка if и выбор цвета. В XML-е писать не удобнее, но даже не в этом суть.
ну например при декларативном биндинге, автоматом работает обновление отображаемого значения при изменении значения проперти в модели.
также например в декларативном биндинге потенциально можно использовать формулу, и подсистема биндинга может её проанализировать, выявить зависимости
от других полей модели и пересчитывать и обновлять отображаемое значение при их изменении.
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
Здравствуйте, Владимир35, Вы писали:
В>Что нужно сделать для создания ГУИ императивно? Даже подумать страшно. Определенные императивные технологии, и некоторые причисляющие себя к "декларативным", такого в принципе не поддерживают.
В императивном стиле это будет выглядеть как вложенные друг в друга циклы или рекурсивные функции. Там все интуитивно понятно.
А вот в декларативном — действительно деревья с ветками разных типов со списками представить сложно.
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
Здравствуйте, Mamut, Вы писали:
M>Потому что ты не зе знаешь никаких других подходов, кроме XAML'а, и делаешь далеко идущие выводы. Например, SwiftUI тоже декларативный, сильно короче XAML'а и короче аналогичного декларативного бкода, и наглядно показывает удобство деклартивного кода и прозрачного связывания данных даже на простых примерах, например тут: https://developer.apple.com/tutorials/swiftui/creating-and-combining-views UI просто становится комбинацией вложенных структур, которые можно как угодно менять и вкладывать друг в друга.
А как там будет выглядеть установка цвета даты в зависимости от четности, к примеру?
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
Здравствуйте, MadHuman, Вы писали:
MH>ну например при декларативном биндинге, автоматом работает обновление отображаемого значения при изменении значения проперти в модели.
А оно не всегда нужно!!! Более того — иногда обновление нужно моментальное (т.е. пользователь еще не успел убрать фокус из элемента ввода) а иногда отложенное. Иногда обновление нужно связанное не с данными а с командой — как то нажатие на кнопку.
MH>также например в декларативном биндинге потенциально можно использовать формулу, и подсистема биндинга может её проанализировать, выявить зависимости MH>от других полей модели и пересчитывать и обновлять отображаемое значение при их изменении.
А ссылку на пример дадите?
Re[3]: Связывание форм (GUI) с данными: императивно vs декларативно
M>>Потому что ты не зе знаешь никаких других подходов, кроме XAML'а, и делаешь далеко идущие выводы. Например, SwiftUI тоже декларативный, сильно короче XAML'а и короче аналогичного декларативного бкода, и наглядно показывает удобство деклартивного кода и прозрачного связывания данных даже на простых примерах, например тут: https://developer.apple.com/tutorials/swiftui/creating-and-combining-views UI просто становится комбинацией вложенных структур, которые можно как угодно менять и вкладывать друг в друга.
S>А как там будет выглядеть установка цвета даты в зависимости от четности, к примеру?
Ты бы мог пройти по приведенной мной ссылке и увидеть сам. Но ты этого делать не собираешься, потмоу что твоя единственная задача — создать информационный шум и побольше тем с целью бессмысленных споров.
Здравствуйте, Shmj, Вы писали:
MH>>ну например при декларативном биндинге, автоматом работает обновление отображаемого значения при изменении значения проперти в модели.
S>А оно не всегда нужно!!! Более того — иногда обновление нужно моментальное (т.е. пользователь еще не успел убрать фокус из элемента ввода) а иногда отложенное. Иногда обновление нужно связанное не с данными а с командой — как то нажатие на кнопку.
если нужно в большинстве случаев, то исключения уже не играют рояль.
к тому же описанные вами варианты, могут быть потенциально реализованы как доп. настройка (проперть) режима декларативного биндинга.
MH>>также например в декларативном биндинге потенциально можно использовать формулу, и подсистема биндинга может её проанализировать, выявить зависимости MH>>от других полей модели и пересчитывать и обновлять отображаемое значение при их изменении.
S>А ссылку на пример дадите?
такое есть внутри нашего проекта, но используется внутренняя реализация.
в общедоступных сходу не припомню, но смутно припоминаю что в каких-то веб-фрэймворках такое видел.
Re[4]: Связывание форм (GUI) с данными: императивно vs декларативно
Здравствуйте, MadHuman, Вы писали:
MH>если нужно в большинстве случаев, то исключения уже не играют рояль.
А вот в этом и ошибка — кто сказал, что нужно в большинстве случаев?
В большинстве случаев ничего не нужно обновлять на форме для каждого элемента. Есть редкие элементы, для которых нужно обновлять форму — либо после того как убрал фокус либо до.
MH>к тому же описанные вами варианты, могут быть потенциально реализованы как доп. настройка (проперть) режима декларативного биндинга.
Проблема в том, что на практике кода меньше не становится
Вроде бы да, двойное связывание (но и оно не всегда нужно!) позволяет писать в 2 раза меньше кода. Однако из-за индивидуальных особенностей каждой конкретной формы, как правило, проигрываешь в другом.
Re: Связывание форм (GUI) с данными: императивно vs декларативно
Здравствуйте, Shmj, Вы писали:
S>Теперь давайте какие реальные плюсы у т.н. декларативного? Букв меньше не стало. Совокупная сложность кода не понизилась — все равно в конвертере есть проверка if и выбор цвета. В XML-е писать не удобнее, но даже не в этом суть.
S>Только вера в то, что декларативно типа круче?
Не вера, а знание. Это ты не веришь, а мы точно знаем
У тебя ошибка в том, что ты сравниваешь количество строк, простоту восприятия этого примитивного примера и относительную лёгкость создания такого кода. Так и есть. Всё верно. На простом примере такой код выглядит проще и писать его легче. Да и на более сложном примере будет примерно тоже самое. Вообще, я считаю, что любой нормальный программист должен без проблем сгенерировать строчек сто кода, которые должны даже работать. Почему все так любят всё переписывать? Потому что на чистом листе ещё нет никаких проблем, пиши себе, излагай мысль, одно удовольствие.
Все проблемы начинаются потом. Когда эти удовольствия и мысли нужно изогнуть в другую сторону, выправить под изменившиеся требования, расширить или наоборот урезать, но не всё, а только часть и сбоку ещё чего-нибудь пришпандорить.
Вот в этом случае императивный подход сосёт у декларативного как трофейный пылесос.
Ценность технологий, паттернов и подходов не в том, чтобы можно было быстро наклепать простой пример или демку (как в Code First). Не в том, что этот примитивный пример получился не в 10 строк, а в 9. Это всё не более чем приятный бонус. Ценность всего этого в том, насколько сопровождаемым и управляемым будет твой код на протяжении всего его жизненного цикла. Сможешь ли ты через год в своём или вообще в чужом коде быстро разобраться в хитросплетениях ифов и циклов? Не на твоём примере, а там где количество строк уже давно за тысячи и руку приложило несколько девелоперов. Я сомневаюсь. А в декларативном коде всё это сделать будет на порядок проще. Потому что его было тяжелее создавать, тяжелее проектировать, поначалу даже больше писать. Зато менять его как два пальца об асфальт.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
Здравствуйте, Mamut, Вы писали:
M>Потому что ты не зе знаешь никаких других подходов, кроме XAML'а
Да и зэмл, а точнее WPF он знает весьма поверхностно.
M>, и делаешь далеко идущие выводы. Например, SwiftUI тоже декларативный, сильно короче XAML'а и короче аналогичного декларативного бкода, и наглядно показывает удобство деклартивного кода и прозрачного связывания данных даже на простых примерах
Даже тут не к месту. Как раз на простыхьпримерах декларативность рулит. Проблемы наступают со сложными, так как императивный код гибче даже хорошего декларативного, и просто на две головы выше плохого декларативного, коего, увы, намного больше.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Связывание форм (GUI) с данными: императивно vs декларативно
НС>Даже тут не к месту. Как раз на простыхьпримерах декларативность рулит. Проблемы наступают со сложными, так как императивный код гибче даже хорошего декларативного, и просто на две головы выше плохого декларативного, коего, увы, намного больше.
Нужна прагматичность: декларативность, где надо, и императивность, где надо Но где ж найти идеал-то...
Здравствуйте, Mamut, Вы писали:
M>Нужна прагматичность: декларативность, где надо, и императивность, где надо Но где ж найти идеал-то...
Даже небольшая примесь императивности все сильно усложняет. Хороший пример — Blend и редактор WinForms. Последний намного более убог, но при этом очень глючен и мутен. Причина как раз наличие неизбежной императивности.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Связывание форм (GUI) с данными: императивно vs декларативно
M>>Нужна прагматичность: декларативность, где надо, и императивность, где надо Но где ж найти идеал-то...
НС>Даже небольшая примесь императивности все сильно усложняет. Хороший пример — Blend и редактор WinForms. Последний намного более убог, но при этом очень глючен и мутен. Причина как раз наличие неизбежной императивности.
Императивщина все равно бывает нужна. Потому что декларативность бывает многословна и/или неэффективна. Или надо работать с императивным кодом. И т.п. Но ее надо ограничивать. Типа «в условиях X мы можем использовать императивный код».
Например, в туториале, что я привел по ссылке, есть раздел «Use UIKit and SwiftUI Views Together»:
struct MapView: UIViewRepresentable {
func makeUIView(context: Context) -> MKMapView {
MKMapView(frame: .zero)
}
func updateUIView(_ view: MKMapView, context: Context) {
let coordinate = CLLocationCoordinate2D(
latitude: 34.011286, longitude: -116.166868)
let span = MKCoordinateSpan(latitudeDelta: 2.0, longitudeDelta: 2.0)
let region = MKCoordinateRegion(center: coordinate, span: span)
view.setRegion(region, animated: true)
}
}
struct MapView_Preview: PreviewProvider {
static var previews: some View {
MapView()
}
}
в update/make позволяется императивный код. Но для кода вокруг получившуюся струтуру все равно можно использовать дебкларативно
struct ContentView: View {
var body: some View {
VStack {
MapView()
VStack(alignment: .leading) {
Text("Turtle Rock")
HStack(alignment: .top) {
Text("Joshua Tree National Park")
Spacer()
Text("California")
}
}
}
}
}
struct ContentView_Preview: PreviewProvider {
static var previews: some View {
ContentView()
}
}
Вот что-то в таком стиле, имхо, — правильный подход.
Здравствуйте, Shmj, Вы писали:
S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?
Потому что суть не в противопоставлении себя "императивщине", а в том, что декларативный подход суть DSL. А это значит, что в твоём "языке ГУЁв" только самые нужные элементы и они заточены на свою задачу, позволяя наиболее мощно описывать решение.
S>Декларативный подход типа:
S>