IMO, if someone tries to upgrade their app to a new SDK and they get compile errors, they will complain and/or not upgrade. It does not make us look good. They may not bother to even read why we did that.
Some people may have working apps where they do mutate the existing field and call refresh(). Seems like you could just copy your current code into ImmutableSortField and restore the old SortField. And you are welcome to add deprecation metadata to the current SortField that tells folks that they are probably better off using the new ImmutableSortField. My 2 cents, -Alex On 11/7/16, 1:17 PM, "Mihai Chira" <mihai.ch...@gmail.com> wrote: >> I guess I >> don't fully understand the issue, so I don't have an alternate proposal, > >To help those reading this anew (but if responding, please also read >the whole thread), the issue is: >1. You have a sorted collection >2. You change any of the properties of the Sort or SortField (the >order, numeric or not, the field by which to sort, the sorting >function, anything) >3. You (or, more frequently, the SDK itself, through a component's >dataProvider) call getItemIndex() or removeItem() or removeAll() on >that collection. > >In this situation there will very likely be a fatal. Reason: refresh() >wasn't called on the collection, so it (as the code is designed now) >assumes that the collection has been sorted by the *modified* sorting >rules, when in reality it's sorted by the original rules. > >There were 5 potential solutions suggested in the thread, and for the >moment I chose the first one (making Sort and SortField immutable, but >with an intermediary stage of hiding the state setters behind >mx_internal for a few "transition" releases), thinking that the >benefits of moving errors from the runtime to compile time is greater >than strict backwards compatibility. (For the code changes this would >imply, see FLEX-34880[1].) > >If, however, we decide that strict backwards compatibility is more >important, I can revert the current changes (which achieved this for >SortField; Sort was pending) and change course (but probably not for >this impending release). If indeed it turns out this change is >undesired, I can also go back and review the other solutions in more >depth. > >For the record, I still personally think that sometimes it's ok to >(minimally) break backwards compatibility (eventually, after a few >transition releases) in favour of a better designed, less >runtime-error prone framework which encourages better coding. What's >good is that people upgrading their projects would get compile errors >rather than changed behaviour at runtime, which is much harder to >detect. And if we document these changes well, it should make it >relatively easy to transition. > >[1] https://issues.apache.org/jira/browse/FLEX-34880
