Здравствуйте, DarkGray, Вы писали:
U>> Во-первых, геттерный подход ортогонален immutable-программированию. DG>если ты про кэши, то это частный случай lazy-программирования
Так immutable или lazy?
U>>Кстати, если геттерный подход это общеизвестно, то с чего это, к примеру, все микрософтовские библиотеки написаны в кошмарном сеттерном стиле? DG>проще обеспечить меньшее кол-во оверхеда и наведенных эффектов.
Смеешься? Событийный подход как способ борьбы с оверхедом и наведенными эффектами это пять. Событийный подход это один большой оверхед и наведенный эффект, т.к. удержать в голове цепочки вызовов событий невозможно даже на простых задачах.
DG>например, ты в курсе, что на lazy-инициализации легко словить зацикленность и stackoverflow?
Каким это образом? При использовании сеттерно-событийных библиотек стектрейсы в десятки вызовов вижу регулярно. При использовании геттерного подхода стектрейс в десяток вызовов еще поискать надо.
Здравствуйте, samius, Вы писали:
S>Даже если посмотреть на вездесущий IEnumerable, то в его контракте заложено именно то, о чем ты выражаешься как "геттерный подход". Изменение коллекции увеличивает версию коллекции, которую кэширует перечислитель.
Я очень рад, что микрософт научился использовать геттерный подход для самых примитивных сущностей. Интересно доживу ли я до того момента, когда микрософт научится использовать геттерный подход для чего-то мало-мальски сложного. Судя по динамике развития за последние десять лет, похоже нет, не доживу.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, samius, Вы писали:
S>>Даже если посмотреть на вездесущий IEnumerable, то в его контракте заложено именно то, о чем ты выражаешься как "геттерный подход". Изменение коллекции увеличивает версию коллекции, которую кэширует перечислитель.
U>Я очень рад, что микрософт научился использовать геттерный подход для самых примитивных сущностей. Интересно доживу ли я до того момента, когда микрософт научится использовать геттерный подход для чего-то мало-мальски сложного. Судя по динамике развития за последние десять лет, похоже нет, не доживу.
Давай попробуем вещь чуть более сложную чем тривиальную.
Есть три сущности A, B, C. У A есть свойство Bar. У B есть свойство Bar, значение которого зависит от значения A.Foo. У C есть свойство XYZ, которое зависит от B.Bar.
В программе меняется нечто, что влияет на A.Foo. Как ты предлагаешь организовать программу, что бы при обращении к C.XYZ мы получили соответствующее значение?
Если суть твоего предложения заключается в переходе от propagation changes к propagation 'changed' flag, то говорить о прорыве не приходится, как собственно и об уменьшении кода.
Здравствуйте, samius, Вы писали:
S>Есть три сущности A, B, C. У A есть свойство Bar. У B есть свойство Bar, значение которого зависит от значения A.Foo. У C есть свойство XYZ, которое зависит от B.Bar.
S>В программе меняется нечто, что влияет на A.Foo. Как ты предлагаешь организовать программу, что бы при обращении к C.XYZ мы получили соответствующее значение?
B.Bar реализуем как автоматический кэш зависящий от A.Foo. Свойство C.XYZ реализуем как автоматический кэш зависящий от B.Bar.
Все, о проблемах с обновлением C.XYZ можно забыть раз и навсегда.
Дополнение. Если от A.Foo зависит на самом деле не B.Bar целиком, а какое-то подсвойство B.Bar, то в виде автоматического кэша надо реализовывать не B.Bar, а это самое подсвойство.
S>Если суть твоего предложения заключается в переходе от propagation changes к propagation 'changed' flag, то говорить о прорыве не приходится, как собственно и об уменьшении кода.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, samius, Вы писали:
S>>Есть три сущности A, B, C. У A есть свойство Bar. У B есть свойство Bar, значение которого зависит от значения A.Foo. У C есть свойство XYZ, которое зависит от B.Bar.
S>>В программе меняется нечто, что влияет на A.Foo. Как ты предлагаешь организовать программу, что бы при обращении к C.XYZ мы получили соответствующее значение?
U>B.Bar реализуем как автоматический кэш зависящий от A.Foo. Свойство C.XYZ реализуем как автоматический кэш зависящий от B.Bar.
U>Все, о проблемах с обновлением C.XYZ можно забыть раз и навсегда.
U>Дополнение. Если от A.Foo зависит на самом деле не B.Bar целиком, а какое-то подсвойство B.Bar, то в виде автоматического кэша надо реализовывать не B.Bar, а это самое подсвойство.
Ага, вижу небольшую проблему, что C.XYZ не вернет значение пока вся цепочка как минимум не сравнит кэшированные значения с значением дальше по цепочке. Т.е. тривиальнейший запрос на значение C.XYZ выполнит обращение к B.Bar, а тот к A.Foo. Т.е. минимальная сложность обращения к чему-то — O(длина цепочки).
S>>Если суть твоего предложения заключается в переходе от propagation changes к propagation 'changed' flag, то говорить о прорыве не приходится, как собственно и об уменьшении кода.
U>Таким умных слов не знаю.
Пропихивание изменений и пропихивание флага об изменениях. Я думал что цепочка будет связываться флагами, как это принято в lazy reactive propgramming, а не кэшами.
Здравствуйте, samius, Вы писали:
S>Ага, вижу небольшую проблему, что C.XYZ не вернет значение пока вся цепочка как минимум не сравнит кэшированные значения с значением дальше по цепочке. Т.е. тривиальнейший запрос на значение C.XYZ выполнит обращение к B.Bar, а тот к A.Foo. Т.е. минимальная сложность обращения к чему-то — O(длина цепочки).
Да, такая проблема есть, при сотнях тысячах вызовов в секунду просаживание производительности становится критичным. Такие места приходится оптимизировать, благо их немного.
S>Пропихивание изменений и пропихивание флага об изменениях. Я думал что цепочка будет связываться флагами, как это принято в lazy reactive propgramming, а не кэшами.
Идею пропихивания флагов об изменении на пальцах можешь объяснить?
U>Каким это образом? При использовании сеттерно-событийных библиотек стектрейсы в десятки вызовов вижу регулярно. При использовании геттерного подхода стектрейс в десяток вызовов еще поискать надо.
class A
{
int Y:lazy(this.Z - 1)
int Z:lazy(this.Y + 1)
}
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, samius, Вы писали:
S>>Пропихивание изменений и пропихивание флага об изменениях. Я думал что цепочка будет связываться флагами, как это принято в lazy reactive propgramming, а не кэшами.
U>Идею пропихивания флагов об изменении на пальцах можешь объяснить?
То же самое что распихивание значений подписчикам (EventHandler<MyEventArgsWithNewValue>), только вместо самого значения распихивается "знание что нечто изменилось" (EventHandler), по которому подписчик сбрасывает кэш.
Этот подход лучше тем, что позволяет пробегать только по цепочке реальных изменений один раз (по всей длине только в худшем случае), потом берет значения из локальных кэшей.
Но обладает тем же недостатком что и пропихивание изменений — нужна подписка на события.
Здравствуйте, DarkGray, Вы писали:
U>>Смеешься? Событийный подход как способ борьбы DG>ты как-то перескочил с setter-ов на события..
Событийный подход это естественное развитие сеттерного подхода. При сеттерном подходе в чистом виде при изменении состояния объекта нужно менять состояние всех объектов от него зависящих. Однако при решении мало-мальски сложных задач оказывается, что в месте модификации мы не знаем какие объекты зависят от изменяемого. Чтобы обойти эту проблему вводят события, позволяя зависимым объектам самим подписываться на изменения. При реализации геттерного подхода в чистом виде необходимости в событиях не возникает.
Здравствуйте, Undying, Вы писали:
U>Смеешься? Событийный подход как способ борьбы с оверхедом и наведенными эффектами это пять. Событийный подход это один большой оверхед и наведенный эффект, т.к. удержать в голове цепочки вызовов событий невозможно даже на простых задачах.
А ты вот это
видео смотрел?
Посмотри насколько "сеттрено-событийный подход" может рулить при правильном применении.
А вообще pull vs push не имеет однозначного выбора. Иногда хорошо одно иногда другое.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
U> Что-то примеры у тебя все надуманней и надуманней.
по текущим данным пик развития мозга приходится на 25 лет, дальше мозг начинает потихоньку деградировать, и программистам все сложнее с каждым прожитым годом делать выводы: как из очевидного примера получается вариант, который появляется в реальном коде, проскакивает тестирование и ломается у пользователя.
видео смотрел? WH>Посмотри насколько "сеттрено-событийный подход" может рулить при правильном применении. WH>А вообще pull vs push не имеет однозначного выбора. Иногда хорошо одно иногда другое.
Как на Rx записывается цепочка асинхронных шагов и ветвления в этой цепочке? Как на нем решать мало-мальски сложные задачи? Например, есть задача — перепрошить устройство. Необходимо выполнить нескольких сотен асинхронных шагов, из которых 6 разнородных, а один из этих шагов надо выполнять несколько сотен раз в цикле. Как решение такой задачи будет выглядеть на Rx?
Здравствуйте, DarkGray, Вы писали:
DG>по текущим данным пик развития мозга приходится на 25 лет, дальше мозг начинает потихоньку деградировать, и программистам все сложнее с каждым прожитым годом делать выводы: как из очевидного примера получается вариант, который появляется в реальном коде, проскакивает тестирование и ломается у пользователя.
Да, к сожалению это заметно. Ты, к примеру, все решения кардинально упрощающие программирование (геттерный подход, gridSynchronizer, taskPulling) предложил именно в 25 лет. А в дальнейшем от тебя что-то ничего толкового не слышно.
В принципе я видел один случай зацикливания на кэше (не в своем коде). Причина была в том, что был нарушен принцип — делегат кэша должен быть чистой функцией, не меняющей внешнего состояния. Соблазн нарушить этот принцип появился из-за того, что gridSynchronizer есть, а написать controlSynchronizer (синхронизирующий россыпь контролов на форме) все руки не доходили. После написания controlSynchronizer'а эта проблема исчезнет.
Здравствуйте, Undying, Вы писали:
U>Как на Rx записывается цепочка асинхронных шагов и ветвления в этой цепочке? Как на нем решать мало-мальски сложные задачи? Например, есть задача — перепрошить устройство. Необходимо выполнить нескольких сотен асинхронных шагов, из которых 6 разнородных, а один из этих шагов надо выполнять несколько сотен раз в цикле. Как решение такой задачи будет выглядеть на Rx?
Скажем, Rx уместен не в прошивалке, а на самом прошиваемом устройстве.
Здравствуйте, Undying, Вы писали:
U>Как на Rx записывается цепочка асинхронных шагов и ветвления в этой цепочке?
Не понял в чем проблема. Пример показать можешь?
U>Как на нем решать мало-мальски сложные задачи? Например, есть задача — перепрошить устройство. Необходимо выполнить нескольких сотен асинхронных шагов, из которых 6 разнородных, а один из этих шагов надо выполнять несколько сотен раз в цикле. Как решение такой задачи будет выглядеть на Rx?
В том видео показано как асинхронно работать с веб сервисом. Чем устройство отличается от вебсервиса не ясно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
U>>Как на Rx записывается цепочка асинхронных шагов и ветвления в этой цепочке? WH>Не понял в чем проблема. Пример показать можешь?
Допустим, нужно перепрошить прибор с сервера. Нужно послать запрос 1, дождаться ответа, проверить ответ, если ответ правильный, то на основе данных полученных из ответа сформировать запрос 2. Затем аналогично послать запрос 2, дождаться ответа, проверить ответ, завершить выполнение, если ошибка, либо сформировать следующий запрос. И т.д. сотню-другую раз. Как это делается на Rx?
WH>В том видео показано как асинхронно работать с веб сервисом. Чем устройство отличается от вебсервиса не ясно.
Там в примере цепочка последовательных асинхронных шагов, зависящих от результата предыдущих шагов была?
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, WolfHound, Вы писали:
U>>>Как на Rx записывается цепочка асинхронных шагов и ветвления в этой цепочке? WH>>Не понял в чем проблема. Пример показать можешь?
U>Допустим, нужно перепрошить прибор с сервера. Нужно послать запрос 1, дождаться ответа, проверить ответ, если ответ правильный, то на основе данных полученных из ответа сформировать запрос 2. Затем аналогично послать запрос 2, дождаться ответа, проверить ответ, завершить выполнение, если ошибка, либо сформировать следующий запрос. И т.д. сотню-другую раз. Как это делается на Rx?
from response1 in Request1()
where Predicate1(response1)
from response2 in Request2()
where Predicate2(response2)
select ...
Здравствуйте, Undying, Вы писали:
U>Допустим, нужно перепрошить прибор с сервера. Нужно послать запрос 1, дождаться ответа, проверить ответ, если ответ правильный, то на основе данных полученных из ответа сформировать запрос 2. Затем аналогично послать запрос 2, дождаться ответа, проверить ответ, завершить выполнение, если ошибка, либо сформировать следующий запрос. И т.д. сотню-другую раз. Как это делается на Rx?
На C# это делать не очень удобно.
Придется писать кучу лямбд и руками подписываться на события.
Но если насыпать сахар в виде ComputationExpressions то получится все очень просто и красиво.
def loop(arg)
{
comp Rx
{
defcomp res = Request1(arg);
if (res.IsError)
loop(arg);
else
Request2(res);
}
}
U>Там в примере цепочка последовательных асинхронных шагов, зависящих от результата предыдущих шагов была?
Такого примера в той презентации нет.
Но он тривиален.
Но там есть очень интересный пример.
От пользователя идет поток событий.
Сначала стоит фильтр который ждет чтобы мужду событиями прошло не меньше Н миллисекунд. Ибо, зачем спамить сервер пока пользователь печатает.
Потом стоит фильтр, который не пропускает два одинаковых события подряд.
Далее делаются запросы к веб серверу.
Причем если очередное событие пришло раньше, чем сервер ответил, то текущий запрос отменяется (он уже не актуален) и посылается новый.
После чего ответ проталкивается в UI.
В коде это описывается 1 в 1 со словесным алгоритмом.
Вообще тебе стоит посмотреть это видео.
Тебя заклинило на pull подходе. А он не всегда оптимален.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
