flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mihai Chira <mihai.ch...@gmail.com>
Subject Re: [jira] [Updated] (FLEX-34853) ListCollectionView.getItemIndex throws RTE when the Sort's sortFields change
Date Fri, 22 May 2015 16:30:42 GMT
On 22 May 2015 at 17:38, Alex Harui <aharui@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

> 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

View raw message