Arguably this would be better because if spread was called in a different context (via bind, call, apply, or by placing it on an object) one might WANT this to point to the context. With null, there is no way to set the context of func from outside.
I just think that the question doesn't care about strict or non-strict mode.So,let's assume the function is in non-strict mode ,then null and this are equal 'cause they all point to global object (non-strict mode). And the null is just cool !
Don't be so negative guys!
I think a few of us, (like myself) have read your comments, meditated on it a bit, and now agrees that you were right.
I did learn from you, thanks!
I've been coming to the conclusion that this site is fundamentally broken in that way. Most katas' top-rated "best practice" solutions have horrible runtime efficiencies and bad practices! By bad practices, I'm thinking of ridiculous trinary-fueled code golf, using double equals comparisons in JS, monkey patching built-in classes or prototypes, or in cases like this, just not providing a solution that works on edge cases.
such algorithm
What if
a == b
on first callwhoa.
Arguably
this
would be better because ifspread
was called in a different context (viabind
,call
,apply
, or by placing it on an object) one might WANTthis
to point to the context. Withnull
, there is no way to set the context offunc
from outside.I just think that the question doesn't care about strict or non-strict mode.So,let's assume the function is in non-strict mode ,then null and this are equal 'cause they all point to global object (non-strict mode). And the null is just cool !
Don't be so negative guys!
I think a few of us, (like myself) have read your comments, meditated on it a bit, and now agrees that you were right.
I did learn from you, thanks!
This is exactly why answers should be run through some real performance testing. sigh.
I've been coming to the conclusion that this site is fundamentally broken in that way. Most katas' top-rated "best practice" solutions have horrible runtime efficiencies and bad practices! By bad practices, I'm thinking of ridiculous trinary-fueled code golf, using double equals comparisons in JS, monkey patching built-in classes or prototypes, or in cases like this, just not providing a solution that works on edge cases.
Codewars is the blind leading the blind.
This solution does not handle the case where the lost number is the last one, e.g. the missing '4' in
[3,1,2]
.Shame on those who marked this best practice.
The ultimate hardcoded solution I've seen at 3kyu.
Mad Props.
good job!
very clever! +1
console.log('anything') on line #1
for some reason that worked for me.
It looks like this will fail if the order of
country/state
andcapital
is reversed in the tests.Loading more items...