[
https://issues.apache.org/jira/browse/FLEX-22649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13738728#comment-13738728
]
Shobhit Samaria commented on FLEX-22649:
----------------------------------------
This seems to be a long outstanding issue and can be very confusing. The bug
seems to mention that the ASDoc needs to be changed which is why maybe it
hasn't been taken up as yet. In my view, sorting and fetching are two distinct
tasks and they really should not be mixed. Equality in terms of sorting can be
completely different from equality when fetching objects. For instance, sorting
only on basis of first names, "John Conner" and "John Doe" can be taken as
equals and one would assume returning 0 is safe but this can be very dangerous
as it can result in the wrong object being fetched by the getItemIndex. The 0
value that the function returns should only and only indicate equal precedence
in a sort and should not be treated as "equality" of objects.
> ListCollectionView getItemIndex does not conform to ASDoc when a Sort is
> applied.
> ---------------------------------------------------------------------------------
>
> Key: FLEX-22649
> URL: https://issues.apache.org/jira/browse/FLEX-22649
> Project: Apache Flex
> Issue Type: Bug
> Components: .Unspecified - Framework
> Affects Versions: Adobe Flex SDK 3.4 (Release)
> Environment: Affected OS(s): All OS Platforms
> Affected OS(s): All OS Platforms
> Browser: Internet Explorer 8.x
> Language Found: English
> Reporter: Adobe JIRA
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
