immutable data structures become more prevalent among JavaScript devel
immutable вполне дружит с databinding-ом. Биндиться будет чуть по другому, а паттерны все те же самые.
В статье под байндингом понимается классическое понятие — есть ссылки на два объекта o1 и o2, когда меняется свойство o1.PropertyA, то внезапным образом меняется o2.PropertyB. Это противоречит неизменности объектов.
В immutable databinding-е используются символические ссылки. Соответственно, там тоже возможна ситуация "когда меняется свойство link("o1").PropertyA, то внезапным образом меняется link("o2").PropertyB".
Плюс immutable окружения, что если держишь прямую ссылку, то данные по ней не меняются.
Плюс immutable окружения, что если держишь прямую ссылку, то данные по ней не меняются.
В immutable databinding-е используются символические ссылки. Соответственно, там тоже возможна ситуация "когда меняется свойство link("o1").PropertyA, то внезапным образом меняется link("o2").PropertyB".link("o1") — это же мутабельность. Сама ссылка является мутабельной.
link("o1") — это же мутабельность. Сама ссылка является мутабельной.1. не чувствую, что корректно такую ссылку называть мутабельной
2. такие ссылки удобный способ для записи dataflow в immutable-окружении. Другие способы - хуже.
1. не чувствую, что корректно такую ссылку называть мутабельнойПо определению — значение ссылки меняется со временем, значит ссылка изменяемая, т.е. мутабельная.
2. такие ссылки удобный способ для записи dataflow в immutable-окружении. Другие способы - хуже.
90% полей в Model не нужны. Не надо их вводить, и ненужные потоки данных уходят.
90% полей в Model не нужны. Не надо их вводить, и ненужные потоки данных уходят.Часть полей нужна, как и часть потоков данных. И необходим способ записи этих потоков.
ps
Потоки данных: "БД => UI", "нажатие кнопки => изменение БД" в любом случае остаются. И необходим способ их записи.
"нажатие кнопки => изменение БД"Собрал значение полей с контролов и записал в базу — чистый имутабельный сценарий.
Если нужна ссылка на паттерн, то это близко к Flow Synchronization.
Собрал значение полей с контролов и записал в базу — чистый имутабельный сценарий.Это не вся программа. Это однократное действие.
Вся программа выглядит так:
(link("контрол"), link("бд")) => link("бд").update(link("контрол").get_data());
БД используется mutable или immutable?
Это не вся программа. Это однократное действие.Сейчас обсуждаем как писать код, который между контролами и бд.
Вся программа выглядит так:
(link("контрол"), link("бд")) => link("бд").update(link("контрол").get_data());
Выполнил sql select, залил значения в контролы.
Прописал обработчики евентов от контролов.
Считал поля из контролов, сгенерировал sql команды insert/update/delete.
Всё это можно просто написать имутабельно.
Т.е. код между контролами и БД проще писать имутабельным, и жизнь станет легче.
Выполнил sql select, залил значения в контролы.Контролы - что такое? Они immutable или mutable?
Как взимодействует между собой обработчики с разной длительностью жизни?
Как записывается dataflow: поменялись данные в БД => перестроить вывод в контролах?
Контролы - что такое? Они immutable или mutable?Mutable, потому что пользователь работает с ними как с мутабельными вещами. То, что в реальной жизни наблюдается как мутабельная вещь, то и в программе это мутабельное. А вот из пальца высасывать мутабельность — это плохо.
Как взимодействует между собой обработчики с разной длительностью жизни?
Не совсем понимаю, что такое "длительность жизни обработчика"? Обработчик это фрагмент кода. Если имеется ввиду долгие операции, то они выполняются в отдельном потоке, а результат приходит в общую очередь обработки эвентов.
Как записывается dataflow: поменялись данные в БД => перестроить вывод в контролах?
Опять такие, это один из видов эвентов, которые поступают в очередь.
Опять такие, это один из видов эвентов, которые поступают в очередь.Фу какая гадость. Event-ы хороши для выполнения, но не для описания устройства программы.
Фу какая гадость. Event-ы хороши для выполнения, но не для описания устройства программы.Я имел ввиду колбеки, а не C# евенты.
Я имел ввиду колбеки, а не C# евенты.Колбеки - зло. Превращают код в спагетти.
Current continuation и его реализация в C# (yield; async/await) намного приятнее для описания кода.
Колбеки - зло. Превращают код в спагетти.В рамках данного треда совершенно не важно чистые это колбеки или async/await. Код между контролами и генерацией sql команд проще писать, читать и сопровождать если не использовать лишнего изменяемого состояния.
Current continuation и его реализация в C# (yield; async/await) намного приятнее для описания кода.
Код между контролами и генерацией sql команд проще писать, читать и сопровождать если не использовать лишнего изменяемого состояния.Имхо, будущее за следующим "бутербродом".
Код записывается, используя mutable-синтаксис.
point.X = point.Y + 3;
Семантика исполнения immutable:
var point_new = point.With(x:point.Y + 3)
Оптимизированное исполнение - mutable, по возможности:
point.X = point.Y + 3
point.X = point.Y + 3;Переприсвоение это и есть изменяемое состояние, это и есть зло. В этом случае нет контроля со стороны компилятора, переставил строки и никто тебе не сказал, что предыдущий автор запретил такое изменение.
point = point.With(x:point.Y + 3)
Переприсвоение это и есть изменяемое состояние, это и есть зло.согласен, поправил
var point_new = point.With(x:point.Y + 3)
В этом случае нет контроля со стороны компилятора, переставил строки и никто тебе не сказал, что предыдущий автор запретил такое изменение.immutable не спасает автоматически от такой ошибки
mutable:
point.X = point.Y + 3;
point.Y = point.X + 3;//ошибка: Y увеличилось на 6, вместо по ТЗ на 3
immutable:
var new_point = point.With(x: point.Y + 3);
var new2_point = new_point.With(y: new_point.X + 3); //ошибка: Y увеличилось на 6, вместо по ТЗ на 3
//ошибка: Y увеличилось на 6, вместо по ТЗ на 3Соответствие кода и ТЗ проверяется однократным тестированием — это недорого. Дорого — перетестировать всю систему при внесении каждого небольшого изменения. Поэтому важен стиль программирования, при котором можно вносить изменения без перетестирования всей системы.
Соответствие кода и ТЗ проверяется однократным тестированием — это недорого.В реальном приложении эта ошибка будет завернута в for-ы, if-ы, настройки окружения, отдельные операции, треды и т.д. И однократным тестированием не проверишь соответствие ТЗ.
Mutable, потому что пользователь работает с ними как с мутабельными вещами. То, что в реальной жизни наблюдается как мутабельная вещь, то и в программе это мутабельное. А вот из пальца высасывать мутабельность — это плохо.У тебя свое понимание иммутабельности, которое не вполне совпадает с общепринятым. В документе, который ты цитируешь, говорится именно о настоящей жесткой иммутабельности. Речь идет об использовании библиотек Immutable.js, mori, которые имплементируют персистентные структуры данных, а также о библиотеках, которые дружат с реакт с персистентными структурами данных, описание идеи тут, список библиотек:
- http://github.com/reagent-project/reagent
- http://github.com/omcljs/om
- http://github.com/reagent-project/reagent
- http://github.com/levand/quiescent
- http://github.com/Yomguithereal/baobab
- http://github.com/mquan/cortex
- http://github.com/dustingetz/react-cursor
Вот содержательный пример иммутабельного приложения (есть единственная мутабельная переменная): демо , код
То, что в реальной жизни наблюдается как мутабельная вещь, то и в программе это мутабельное. А вот из пальца высасывать мутабельность — это плохо.В программировании мы имеем дело с абстракциями, никакого "реального мира" нет, есть его модель. Моделировать реальный мир можно как мутабельным языком, так и иммутабельным. Ты демонстрируешь правоту гипотезы Сепира-Уорфа в применении к C# - на основе того что в C# невозможно иммутабельное программирование, ты делаешь вывод что мутабельность присуща реальному миру.
Имхо, если мы не рассматриваем вопросы производительности, а просто пишем прикладное приложение, то мутабельность не нужна, все то же самое можно не менее удобно запрограммировать на иммутабельном языке. Можно рассмотреть контрпримеры к этому тезису.
В программировании мы имеем дело с абстракциями, никакого "реального мира" нет, есть его модель.Окружение программы мутабельно: время, сервисы, ОС, пользователи и т.д.
залил значения в контролы.По сравнению с этим эксель кажется футуристической средой программирования из будущего.
Прописал обработчики евентов от контролов.
Считал поля из контролов
По сравнению с этим эксель кажется футуристической средой программирования из будущего.Ты поклонник Visual Basic for Application?
Ты поклонник Visual Basic for Application?По крайней мере там не надо добавлять обработчики событий от ячеек чтобы посчитать что-то по формуле
Оставить комментарий
6yrop
Ну наконец то школота понимает, что датабайдинг не нужен.