> Folks keep trying to find ways to avoid calls to refresh() and we keep > ending up with other side-effects. Seems dangerous (from a backward > compatibility standpoint) to be making changes like this. When they do that they run into the risk of forgetting to call refresh() in time, or at all. Keep in mind that this sort of behaviour wasn't foreseen by SDK developers (for example when implementing FLEX-33248[1]), so application developers not familiar with the inner workings of the SDK are even more likely to run into these scenarios. To me bugs like FLEX-34838 should be avoided by making it impossible for developers to run into them. The possible solutions that I see are: 1) make Sort and SortField immutable, thus forcing developers to create new instances to re-assign to collections, or 2) get the collections to detect changes to Sort, SortField and filterFunction but only refresh() internally when getItemIndex(), removeItem() or removeItemAt() are called, or 3) get the collections to detect changes to Sort, SortField and filterFunction and refresh immediately or some combination of the above, which can still allow developers to delay the collection's re-sorting/filtering, and also make these runtime errors a thing of the past.
The way I see it is that to keep this potential for unintended behaviour in the SDK is to waste a lot of development time on debugging "weird" outcomes (I say a lot because they only become obvious at runtime, and under specific circumstances). It's these weird outcomes that we have a chance to make impossible in the first place, thus saving people time. The more we can move dangerous runtime errors to become compile errors the better. [1] https://issues.apache.org/jira/browse/FLEX-33248
