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.) > 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. Updating ASDocs to clarify this behaviour is definitely a good idea. As for try/catch, I'd prefer to find a way to make it impossible to get a runtime error in those functions (at least in these use cases). > A new set of Sort classes that refresh on every change would be option #5. I'll take that into consideration, good idea. > Anyway, thanks for working on these issues, > -Alex No, thank you for these really useful comments. [1] https://en.wikipedia.org/wiki/Domain-driven_design [2] http://martinfowler.com/bliki/ValueObject.html [3] http://stackoverflow.com/questions/4581579/value-objects-in-ddd-why-immutable
