CD
зависит от тулинга, в винде вон страдают 40 лет и ничего
винда использует встроенные обработчики с трансляциями, если посмотреть там условно что такое LBUTTONDOWN
Size: a a a
2020 August 11
T1
ща просто читал какую-то приколную статью, а она оказалась @gitkpp
T1
прикол
CD
там инпут идет в диспетчер, дергает NCHITTEST, синтезирует LBUTTONDOWN, если он реджектится все повторяется
CD
прямая завязка на то, что реджект сообщения привел к изменению контекста
CD
в том то и дело что циклы у тебя навязанные, можно без них, мессадж-пассингом например
соответственно в F-моделях тебе надо четко делить сообщения, у тебя получается запросы на действия, которые могут приводить к полиморфным мутациям, и вся вот эта вот дребедень
NL
CD
в том то и дело что циклы у тебя навязанные, можно без них, мессадж-пассингом например
да, я уже молчу, что либо связанные sibling-вьюхи друг об друга вяжутся узлом, либо пересылают запросы через предка формируя God Object, либо не мутируют и используют контекстно-зависимое определение себя :)
CD
причем первый способ самый простой в смысле макакинга, просто храним handle и делаем sendmessage и плевать что он там мб сдох (не сдох, мамой клянусь)
NL
да, я уже молчу, что либо связанные sibling-вьюхи друг об друга вяжутся узлом, либо пересылают запросы через предка формируя God Object, либо не мутируют и используют контекстно-зависимое определение себя :)
Что-то сложно у тебя. Почему тогда просто не взять TEA?
Там можно зацикливаться сколько угодно, и проблем с пропагейтом мутаций нет. Вьюхи образуют гармоничную древовидную структуру.
В сущности единственная большая проблема TEA -- это положительная обратная связь, когда обработчики сообщений вызывают новые сообщения, что приводит ко взрыву их количества.
Там можно зацикливаться сколько угодно, и проблем с пропагейтом мутаций нет. Вьюхи образуют гармоничную древовидную структуру.
В сущности единственная большая проблема TEA -- это положительная обратная связь, когда обработчики сообщений вызывают новые сообщения, что приводит ко взрыву их количества.
CD
Что-то сложно у тебя. Почему тогда просто не взять TEA?
Там можно зацикливаться сколько угодно, и проблем с пропагейтом мутаций нет. Вьюхи образуют гармоничную древовидную структуру.
В сущности единственная большая проблема TEA -- это положительная обратная связь, когда обработчики сообщений вызывают новые сообщения, что приводит ко взрыву их количества.
Там можно зацикливаться сколько угодно, и проблем с пропагейтом мутаций нет. Вьюхи образуют гармоничную древовидную структуру.
В сущности единственная большая проблема TEA -- это положительная обратная связь, когда обработчики сообщений вызывают новые сообщения, что приводит ко взрыву их количества.
Вьюхи образуют гармоничную структуру гетерогенного дерева. Лист А (чекбокс) хочет сказать листу Б (чекбокс), что необходимо изменить состояние (мы реализуем синхронизированные чекбоксы). Как это делается?
CD
1. Отправкой сообщения "сделай состояние" и плевали на лайфтаймы
2. Отправкой сообщения "синхронизируй состояние" предку
3. Записью в единый источник данных информации о собственном состоянии, которое вычитывается каждый раз при получении любого сообщения
2. Отправкой сообщения "синхронизируй состояние" предку
3. Записью в единый источник данных информации о собственном состоянии, которое вычитывается каждый раз при получении любого сообщения
AZ
да, я уже молчу, что либо связанные sibling-вьюхи друг об друга вяжутся узлом, либо пересылают запросы через предка формируя God Object, либо не мутируют и используют контекстно-зависимое определение себя :)
если так сейчас везде делают не значит что это единственно правильно
AZ
просто в ООП это работает и всем норм
CD
если так сейчас везде делают не значит что это единственно правильно
Это неустранимые мутируемые шаред данные, как IO неустранимая грязность. Все, что мы можем сделать - поднять до main
AZ
Это неустранимые мутируемые шаред данные, как IO неустранимая грязность. Все, что мы можем сделать - поднять до main
с ио странная аналогия, с ним как раз можно всю грязь выкинуть за ИО и считать что её нет
CD
с ио странная аналогия, с ним как раз можно всю грязь выкинуть за ИО и считать что её нет
Грязь можно поднять до среды выполнения, схема 3
NL
1. Отправкой сообщения "сделай состояние" и плевали на лайфтаймы
2. Отправкой сообщения "синхронизируй состояние" предку
3. Записью в единый источник данных информации о собственном состоянии, которое вычитывается каждый раз при получении любого сообщения
2. Отправкой сообщения "синхронизируй состояние" предку
3. Записью в единый источник данных информации о собственном состоянии, которое вычитывается каждый раз при получении любого сообщения
Да почему плевали то? После получения сообщения оно деконструируется и время жизни сообщения заканчивается.
Время жизни дерева моделей = времени жизни всего приложения, но сами листья и поддеревья динамически создаются и уничтожаются.
Время жизни дерева вьюх тоже, и сами листья и поддеревья динамически создаются и уничтожаются.
Время жизни дерева моделей = времени жизни всего приложения, но сами листья и поддеревья динамически создаются и уничтожаются.
Время жизни дерева вьюх тоже, и сами листья и поддеревья динамически создаются и уничтожаются.
AZ
Грязь можно поднять до среды выполнения, схема 3
но более общим правилом будет просто не писать гуй на расте пока не придумают хороший фреймворк
CD
Да почему плевали то? После получения сообщения оно деконструируется и время жизни сообщения заканчивается.
Время жизни дерева моделей = времени жизни всего приложения, но сами листья и поддеревья динамически создаются и уничтожаются.
Время жизни дерева вьюх тоже, и сами листья и поддеревья динамически создаются и уничтожаются.
Время жизни дерева моделей = времени жизни всего приложения, но сами листья и поддеревья динамически создаются и уничтожаются.
Время жизни дерева вьюх тоже, и сами листья и поддеревья динамически создаются и уничтожаются.
Лист А не понимает свое отношение лайфтаймов с листом Б