Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added internal _isArray function and replaced 5 instances of constructor... #303

Closed
wants to merge 2 commits into from

Conversation

brianmaissy
Copy link
Contributor

... === Array checking

Solves issues #302 and #179.
Replaces pull request #294, which should be closed.

@@ -70,6 +70,16 @@
return keys;
};

var _isArray = function(maybeArray){

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

var isArray = Array.isArray || function(maybeArray){
  return {}.toString.call(maybeArray) === "[object Array]";
};

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is that considered better style? I just wanted it to be clear in the code that it was our own function. Using the shim can make it unclear.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to name it with an underscore _isArray, as @brianmaissy suggests, to make it clear that it's our version of it, but I also prefer @michaelficarra's implementation which avoids an extra function call in the case that Array.isArray exists.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah good point. i'll commit again.

@michaelficarra sorry, I read your comment too quickly and thought you were suggesting Array.isArray ||=...

What do you think about {} vs Object.prototype? I'm inclined to prefer the extra clarity of Object.prototype even though it's longer.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Less statically analysable. The interpreter has to resolve both Object (in the scope chain) and prototype (in Object' s prototype chain). With {}, you know immediately to look at the Object.prototype object.

Either way, it doesn't really matter. I was just showing you that there is a reason to choose one over the other, though, if you really care.

@pithu
Copy link

pithu commented Jun 21, 2013

+1 vote, because tests with the sandboxed-module are failing with code using async.

@chuggins
Copy link

+1 as well, this breaks tests that override constructors for introspection

@gregberge
Copy link

+1 please merge !

@salper
Copy link

salper commented Dec 7, 2013

+1

@jmdobry
Copy link

jmdobry commented Dec 28, 2013

👍

This fixes #392 and #393, and it's already been mentioned that this fixes #3, #179, #344 and #832. Why hasn't this been merged and these issues/pull requests closed?

Fixes #3! This is an old, old outstanding bug. Dead easy fix.

No new releases for 11 months. This is a ~7,000 star project on GitHub. Has it been abandoned? 200 outstanding issues?

Does anyone know of an up-to-date and actively maintained fork?

@gregberge
Copy link

@jmdobry have you found a maintained fork ?

@vvo
Copy link
Contributor

vvo commented Jan 7, 2014

@caolan @brianmaissy can we get this merged?

@jmdobry
Copy link

jmdobry commented Jan 7, 2014

@neoziro No, might just have to start one.

@brianmaissy
Copy link
Contributor Author

sorry guys, i haven't been contributing to this project for a while. try emailing caolan

@caolan
Copy link
Owner

caolan commented Mar 28, 2014

fixed in d5d0efb

@caolan caolan closed this Mar 28, 2014
@vvo
Copy link
Contributor

vvo commented Mar 28, 2014

@caolan Nice! Thank you

@gregberge
Copy link

@caolan thanks

@michaelficarra
Copy link

@caolan: Are you sure? Did you push it? Github can't find the commit: d5d0efb

edit: I've found this commit: 9f57a35

@pithu
Copy link

pithu commented Apr 1, 2014

@caolan great thanks

nazomikan added a commit to nazomikan/async that referenced this pull request May 19, 2014
* waterfall call in another context
* parallel call in another context
* series call in another context
@nazomikan nazomikan mentioned this pull request May 19, 2014
caolan pushed a commit that referenced this pull request May 27, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants