A bigger irony is use a design pattern i.e. prototype to justify avoiding learning OOP. I can put the output of this problem in babeljs in ES5 but I'm pretty sure that you will say something like adding OOP approach in ES5 is too complex for most users and too boilerplaty
Glad you could solve it.
I have to apologize ... :-(
Read the posts below yours, it'll give you an idea about what's going on.
If you're asking this question then that means you haven't got the idea of the kata yet. So it's not an issue.
Since the specification of the function says "remove the last element", but you expect an array with eight elements when you input a ten element array, I know why the random tests fail.
So, what's the goal of this kata? Expect that your costomer doesn't know what he really wants?
The irony in ES6 being called "classical".
Not an issue.
Not an issue ;-)
That's just sementic difference ;-)
oh, ok. ;-/ (oops)
Looks like a valid issue. It's in the prototype, "static" methods aren't normally there, so it's not even fixable on solution level. Same for Ruby. Same for Python but solutions may define the method static without losing compatibility there. In C# it's correct.
Nope, I don't think so.
Considering the description, the remove method is a static method (thinking about Java. I don't do JS. I guess that will be the same) because the list is passed through the method name.
Now, mutating the list could be another possibility, yes. But that's something different from what is suggested here. Moreover, this way not any input would be requiered.
So, not an issue but rather an opinion. ;)
Note: But I conceed that the definition of the function in a class has effectively (almost?) no interest, here.
integer_list should not be given as parameter but via the this reference.