If you’ve been following the FlexJS stuff, you know that I am a “pay-as-you-go” advocate. I tend to lean against fancy code that, while it makes development faster, is still running at run-time. You can say that a simple flag and the code to test whether to call refresh() doesn’t take many CPU cycles and you would be right, but the Flex SDK is evidence that when you add little bit of code like this thousands of times it adds up to something.
So, my philosophy would be to think of ways to make sure folks don’t forget to call refresh(). In FlexJS, if we implement the same sort capability, we might have a “debug-mode” collection that throws a more useful error like “did you forget to call refresh()” where the “release-mode” collection doesn’t do that checking and thus runs smaller and faster. For the current Flex SDK, if you want to add another little bit of code like you suggest in #2 I won’t object because after a 1000 such changes, the 1001th change isn’t going to truly be noticed. I am only looking out for serious performance hits and breaking API behavior, so Tom’s warning about refreshing on every change is probably worth listening to. Adding try/catch around the point where getItemIndex throws the exception, detecting that a sort is in play and throwing a more useful exception message and/or adding a trace statement about calling refresh() would be an option #4. A new set of Sort classes that refresh on every change would be option #5. Anyway, thanks for working on these issues, -Alex On 5/22/15, 8:12 AM, "Mihai Chira" <mihai.ch...@gmail.com> wrote: >> 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
