On 5/22/15, 9:30 AM, "Mihai Chira" <mihai.ch...@gmail.com> wrote:
>On 22 May 2015 at 17:38, Alex Harui <aha...@adobe.com> wrote: >> 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. >I agree, which is why, after recalling some things I learned about >value objects from DDD[1] and other [2] places [3], I'm leaning toward >at least a partial implementation of #1, because Sort and SortField >have all the characteristics of value objects. This would change the >API somewhat, but only as much as requiring developers to create new >SortField or Sort objects if they want to apply different sorting >criteria. > >> 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(). >...or reuse Sort / SortField objects between collections, which can >lead to the same problem. (Though if option #1 is implemented, reusing >them becomes safe, because their state cannot be changed.) I’m a little concerned that someone somewhere is relying on sharing a mutable SortField, so I’d be careful about making a change like that. At least, add an mx_internal flag to get back old behavior so if someone does complain they have a way of recovering. It might still be safer to implement a new set of Sort classes that are immutable. Anyway, be careful, and good luck. -Alex
