Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
Adobe Flex SDK 3.4 (Release)
-
None
-
None
-
Affected OS(s): All OS Platforms
Affected OS(s): All OS Platforms
Browser: Internet Explorer 8.x
Language Found: English
Description
Steps to reproduce:
1. Create a new ArrayCollection
2. Add a sort that uses a compare function
3. Have this compare function return -1 OR 1, instead of 0 when objects are equal. See sortFunction in Test.mxml
4. add an object to that array collection
5. call getItemIndex() on that array collection
Actual Results:
getItemIndex() returns -1
A side effect is that if you call removeItemAt(0), the item at index 0 is properly removed from the ArrayCollection, but no COLLECTION_CHANGE event is dispatched.
The ArrayCollection's localIndex gets out of sync with the wrapped list.
Expected Results:
According to the doc, getItemIndex should return 0 since the item is in the ArrayCollection and item == getItemAt(0);
Workaround (if any):
Adobe should fix the doc to mention that getItemIndex will use the sort's compare function.
Developers must correctly implement the compare function by making it return 0 when comparing an object to itself and not believe getItemIndex()'s documention
Calling refresh gets the ListCollectionView back in sync, but is not an option, since the COLLECTION_CHANGE "remove" event will not be triggered: some information is lost.
Discussion:
It turns out the getItemIndex implementation is using the Sort's compareFunction.
The implementation itself is pretty clever, both efficient and compact, however it has side effects the doc should mention.
This wrong documentation can result in side effects that are very hard to track down (such as the COLLECTION_CHANGE event not being dispatched). A simple line mentionning the behaviour will avoid it.
This is very misleading, since the use of instance equality is constantly used by the framework, and even though Sort's field is called compareFunction, nothing in the Sort doc nor the ListCollectionView mentions that if a Sort is set, it will be used for retrieving objects, the only use case it mentions is sorting.
When you consider that the Sort's compareFunction must return exactly 1, 0 or -1, instead of the more common and convenient negative, 0 or positive, this can become a problem.
In the attached example, the natural implementation would be : return a.myInt - b.myInt;
Because return value must be -1, 0 or 1, developers will have to write something like:
var diff:int = a.myInt - b.myInt;
return diff == 0 ? 0 : diff < 0 ? -1 : 1;
If you believe that the Sort is used only for sorting, as coined by the doc, you might very well take a shortcut and end up writing return diff < 0 ? -1 : 1;
Which would be correct for sorting, but not for comparing.
Anyway, aside from philosophical considerations, the doc is incorrect and should be updated to mention the use of Sort's compareFunction when set.