Skip to content
This repository has been archived by the owner on Jul 14, 2022. It is now read-only.

Array.prototype.find() and Array.prototype.findIndex() issues #24

Open
sainaen opened this issue Jan 14, 2015 · 2 comments
Open

Array.prototype.find() and Array.prototype.findIndex() issues #24

sainaen opened this issue Jan 14, 2015 · 2 comments

Comments

@sainaen
Copy link

sainaen commented Jan 14, 2015

Hi,

I'm working on adding support for arrow functions (actually it's overstatement, I'm just polishing implementation done by @tuchida in this mozilla/rhino PR) and I've found two problems with 'find()' and 'findIndex()' that were added recently.

First, for code

[1,2,3].find(i => i % 2 == 0)

Rhino will throw rather funny exception

js: uncaught JavaScript runtime exception: TypeError: org.mozilla.javascript.ArrowFunction@34fe7e0e is not a function, it is function

because it expects to get only instances of NativeFunction as a callback (this check is done only for find() and findIndex()), and here I'm passing an instance of ArrowFunction.

Second, for code

var a = [1,2,3];
a.find(function (i) { return i % 2 == 0; }, a);

Rhino will throw

js: uncaught JavaScript runtime exception: TypeError: Array.prototype method called on null or undefined

because again it expects that for find() or findIndex() second argument (thisArg) should never be the same as array itself on which these methods were invoked.

I suppose, both are just mechanical errors, but they were commited with message "more V8 compatibility" and I want to be sure that I'm not breaking anything while removing those checks.

//cc @eshepelyuk

@gbrail
Copy link

gbrail commented Jan 14, 2015

Evgeny put in those changes in order to maintain compatibility with V8 for the new features, but without breaking backward compatibility for existing Rhino users of other functions, so he's probably the best one to address your issue.

@eshepelyuk
Copy link

I propose to change conditions, to start relying on RHINO version flag, that will be introduced in #26, instead of analyzing method names.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants