I am not sure I understand well how isc.list.contains is supposed to work. Using V8.0 seems to yield different results using contains VS containsAll. You can use this code to test it out:
List is an Interface, which you can think of as similar to a Java AbstractClass. It will have unexpected behaviors if you haven’t implemented the methods necessary to complete the implementation.
Concrete implementations are ResultSet and Tree, and the JavaScript native Array is also retrofitted to support the List interface.
Thanks for the clarification. I thought all methods are implemented.
I posted this example in an effort to create the simplest test case.
I actually got here from getting the same behavior on the ListGrid.data implementation of the List class. I was using a ListGrid with local data supplied via the data member and I tried to check whether it contains such an object. While one may argue that using a construct such as {AreaCode: ‘123’} in two different places will yield two different objects that are not equal, a concrete usage scenario would often requires such checking. So it might make sense to make the List (and to a larger extent the Array) check against the object properties instead of performing a simple comparison. Maybe supply a different method?
Of course, this is just a suggestion on how the framework support for the built in JS objects can be improved.
Sorry, no, the original test case was wrong. contains() works by object identity, not matching properties, and this is as it should. Use find() to find objects by matching properties, no need for iteration.