-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Be even more explicit about the semantics of _.isEmpty #2840
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
Be even more explicit about the semantics of _.isEmpty #2840
Conversation
This is meant to address jashkenas#2804.
Thanks @jashkenas. As I understand it, you are fine with the current change (given that I have removed the counter-example that you rightly pointed out). So if @mcurrao requests no further changes, I'll not request another review from you before merging this. |
@jgonggrijp LGTM. Only missing elements would be functions, but as they can be considered non-enumerable objects, I guess there is no need to include them. Thanks! |
Sorry, requesting another review anyway because I just noticed a tautology in the code and removed it. |
This reverts commit 0252976 and addresses the review comment below: jashkenas#2840 (comment)
After optimizing the internal tagTester function, I decided to re- evaluate the optimization and benchmark discussed from jashkenas#2840 (comment) onwards. Now that tagTester is faster, the tradeoff posed by this optimization had become less obviously in favor. Especially evaluating the length of strings appeared to be relatively costly. I realized this was happening twice, so I removed the redundant evaluation. This could be done at a net zero weight change.
This is meant to address #2804.
@mcurrao Please let me know whether this sufficiently addresses the problem for you.