This may affect mx only projects (in FB at least) where spark related swc's are removed when selecting "mx only" as the project's component set.
On 9/06/2015 13:33, Mihai Chira wrote:
I'm making lots of changes to SortField and Sort, and I'm realising that having two versions of these files is error prone and duplicates effort. From what I can see, the differences are: Between mx.collections.SortField and spark.collections.SortField: 1. lots of asdocs changes 2. spark version ignores the caseInsensitive option 3. spark version extends AdvancedStyleClient, and has some more functions for dealing with styles (like a "locale" style) 4. spark version uses a SortingCollator to compare strings, while mx version uses ObjectUtil.stringCompare(), which uses String.localeCompare(). Not sure how different these are. Apart from a couple of bug fixes applied to both (except the bugs I'm working on right now, which I currently only applied to the mx version), they both arrived from the Adobe donation with these differences. Between mx.collections.Sort and spark.collections.Sort: 1. again, lots of asdocs changes 2. again, spark version extends AdvancedStyleClient, and has some more functions for dealing with styles (like a "locale" style) 3. mx version uses Array.sortOn when it can, while spark version doesn't (in the sort() function) And the same as above, apart from a couple commits, they both came from the Adobe donation with these differences. Questions: 1. Can the spark versions be used with the mx components which currently use the mx versions of Sort and SortField? I.e. AdvancedDataGrid, DataGrid and DefaultCubeImpl. Or would there be problems about these new style functions, or other issues? 2. If we can get the above to work, can we get rid of the mx versions? I think it's really important to remove duplication, because all changes to one version (e.g. the ones that I'm now making to sorting) might have unintended consequences when ported to the other version (or, even worse, we'll simply forget to do it, and still keep the bug in the other version), and maintaining two almost identical sets of unit tests is just impractical - not only would we have to make changes and fixes in two places, but we'd also have to update two sets of unit tests each time. Thoughts?
