What if we use WebIDL algorithm for `item()` ?

[hax]

So we will not have many web compat issues, only need to check negative index issue.

---

Another option is throwing RangeError if index is out of range (include Infinity), but allow ObservableArray still returns null (and coerce Infinity to 0). As type theory, subclasses could accept the arguments which base class not.

[tabatkins]

It's definitely possible! In fact, we could mix-and-match features from the existing WebIDL .item() impls and the JS .slice() impls.

• Returning null would be a break from JS tradition, but it would also avoid the largest compat risk (people currently testing the return value of the DOM methods with === null). I don't think I want to do this by default, but I'm open to it if compat data indicates it's needed.
• Treating Infinity as 0, per IDL, rather than keeping it as-is and always being out-of-bounds, would be a minor change that I doubt would affect anything, but I also doubt it's a compat issue we need to worry about. (-Infinity already acts like 0 in both cases, due to the clamping of negative values.)
• Small negative indexes getting modulo'd to positive indexes near 2**32 isn't something we can do, as it defeats the entire purpose of the method. ^_^

Another option is throwing RangeError if index is out of range (include Infinity)

This would be inconsistent with how indexing works in general, across all the methods that let you index into a collection. All of them are perfectly fine with oob indexes, and this ends up being very convenient for writing code, as you can just check for undefined as a sentinel value rather than having to wrap your code in try/catch or pre-test against the length. I would object to this pretty strongly.

[hax]

The point here is, u can't differentiate undefined from oob or empty item or real undefined item. Note this problem does not exist in TypedArrays and Web APIs (as I know, Web APIs never return list with empty items or undefined items) so they can returns null for oob.

rather than having to wrap your code in try/catch or pre-test against the length

This problem could be solved by allowing the second param as fallback value.

[tabatkins]

This problem could be solved by allowing the second param as fallback value.

That wouldn't solve my problem, which is that this would then be inconsistent with all the existing DOM usages of .item().

[hax]

@tabatkins We always need to introduce inconsistency in some degree. On deciding what oob should behave, if we could always return undefined that will be great, but if it mostly returns undefined but returns null in DOM, that will be weird. This is why I suggest throwing while allow DOM still returns null, because it's slightly more "consistent" as type theory. But I agree it still weird.

Anyway, I realize the idea of second param could be an individual enhancement. We always have the issue of differentiating real undefined from oob or empty item which require a extra in check, (Map.p.get have the similar issue), so maybe I should create an separate issue for second param idea.

[tabatkins]

if it mostly returns undefined but returns null in DOM, that will be weird

Agreed, which is why we're going to try some compat analysis to see if switching the DOM stuff to returning undefined is web-compatible. ^_^ If we can't, then either this method will switch to returning null, or we'll change the name of the method so it doesn't collide with the DOM one while having slightly different semantics.

[hax]

Changing name seems not solve the original motivation of item()on ObservableArray?

[tabatkins]

Right, it doesn't. The premise is that if we can't define this method in a way that's consistent with the DOM methods, then it's better to use a different name entirely.

[Jack-Works]

but the main reason and benefit of this proposal are to enable DOM to use ObservableArray. I think we must copy the DOM algorithm and not modify them anyway

[tabatkins]

I'm unsure what behavior you're arguing for here, @Jack-Works.

[Jack-Works]

@tabatkins I'm supporting to match the algorithm defined in the DOM.

[hax]

This proposal already achieve stage 3 , and I assume all DOM .item() would change to the semantic of this proposal without compatibility issue in real world, so i'd like to close this issue.