Allow indexed access for non-NSArray collections#391
Conversation
Indexed access from JS (obj[i]) only worked when the native object was an NSArray, because the getter checked isKindOfClass:[NSArray class]. Switched that to a capability check so anything responding to both count and objectAtIndex: is indexable too, like PHFetchResult and NSOrderedSet. The setter still only accepts NSMutableArray so we don't try to mutate read-only collections.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughArgConverter::IndexedPropertyGetterCallback now treats any Objective-C object that responds to ChangesDuck-typed collection indexing
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
NativeScript/runtime/ArgConverter.mm (1)
886-897: ⚡ Quick winAdd regression tests for new duck-typed indexable collections.
Line 886 introduces a broader capability check (
count+objectAtIndex:), but this behavior change is not protected by tests in this PR. Please add a TestRunner case that verifiesobj[i]on at leastNSOrderedSet(and ideally another non-NSArraytype) including out-of-range behavior.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@NativeScript/runtime/ArgConverter.mm` around lines 886 - 897, Add regression tests exercising the new duck-typed indexable behavior introduced in ArgConverter.mm (the count + objectAtIndex: check) by adding a TestRunner case that (1) creates an NSOrderedSet and at least one other non-NSArray indexable (e.g., PHFetchResult / custom object that implements count and objectAtIndex:), (2) verifies that Objective-C indexing via obj[i] returns the same elements as NSArray-style access for valid indices, and (3) verifies out-of-range behavior (confirm it returns nil or the same error/behavior as NSArray in the runtime) for indices >= count; place assertions in the TestRunner so this new behavior is covered by the test suite.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@NativeScript/runtime/ArgConverter.mm`:
- Around line 886-897: Add regression tests exercising the new duck-typed
indexable behavior introduced in ArgConverter.mm (the count + objectAtIndex:
check) by adding a TestRunner case that (1) creates an NSOrderedSet and at least
one other non-NSArray indexable (e.g., PHFetchResult / custom object that
implements count and objectAtIndex:), (2) verifies that Objective-C indexing via
obj[i] returns the same elements as NSArray-style access for valid indices, and
(3) verifies out-of-range behavior (confirm it returns nil or the same
error/behavior as NSArray in the runtime) for indices >= count; place assertions
in the TestRunner so this new behavior is covered by the test suite.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: a76db5ad-c7e4-4afe-8a22-8c1226e52930
📒 Files selected for processing (1)
NativeScript/runtime/ArgConverter.mm
|
@coderabbitai Good call. Added a TestRunner regression case in |
|
Tip For best results, initiate chat on the files or code changes.
🐇 ✨ |
Right now
obj[i]from JS only works when the native object is an NSArray, because the indexed getter checksisKindOfClass:[NSArray class]. Plenty of other ordered collections are just as indexable but get left out. The one that bit us wasPHFetchResultfrom the Photos framework.This swaps that NSArray check in the getter for a capability check: if the target responds to both
countandobjectAtIndex:, treat it as indexable. NSArray keeps behaving exactly like before, and things like PHFetchResult and NSOrderedSet start working. The bounds check is unchanged, so out of range still returns nothing.A few notes:
countbut notobjectAtIndex:, so they're unaffected, and NSPointerArray usespointerAtIndex:rather thanobjectAtIndex:, so it gets skipped instead of crashing.Happy to add a TestRunner case if you want one in the PR. NSOrderedSet is an easy one since it needs no permissions.
Summary by CodeRabbit