а вообще в "последнее время" набирает обороты подходы со стейтами (снепшот всего состояния вью, тот же MVI). У мокси подход через список дифов (история изменений), отсюда все эти стратегии, извечные вопросы какую же выбрать, сохранять ли действие в истории или нет и т.д. Избыточно, как по мне.  История развития VCS  похожа в этом плане, гит юзает снепшоты, тогда как ранние представители работали с "дифами". П.С. Вот это я подкинул темку в чатик по "мокси", пж не бейте ногами)

у mvi свои "приколы" есть, не призываю тащить ее сразу в прод, но ознакомиться стоит)

а можете объяснить, почему такого быть не должно?

Представьте, что у View есть геттер. Что он должен вернуть презентеру, если будет вызван в момент, когда View не приаттачено к презентеру?

у вью и презентера должен быть односторонний флоу

один приказывает что делать, а второй докладывае то том, что произошло

необязательно, есть вариации MVP где View с геттерами.

Но не в Мокси)

в мокси нету ограничений, это отвественность разработчика, можно и не воид впхнуть

т.е. только в этом проблема?

Это, разумеется, не так :)

Я думаю, что в этом одна из причин, почему авторы изначально отказались от геттеров во View.

в гугле тоже думали, что разработчики будут "правильно" использовать механизмы для работы в фоне, как результат с каждой обновой получаем жесткие ограничения. Это я к тому, что если мокси явно не запрещает, значит можно, а следователньо так будут делать

Другая, более высокоуровневая, в том, что описал Арсен. Проще жить, когда поток управления в одну сторону.

Дык я вам и говорю, что запрещает. Оно не должно компилироваться просто.

аа, знач я не так понял)

А вот почему компилируется - интересно, посмотрю на досуге.

раньше не было такого, давно не юзал мокси)

может это у вас в компании "инструментарий\конфиг" какой-то?

подождите, Вы сейчас конкретно про мокси говорите?