You did a blind copy / paste there didn't you? I didn't completely type out the new version though - read it carefully ..

Thank you for suggestion
I changed the description

More kata combine functionality from other kata

Not gonna argue. But I'd rather do a bunch of existing katas, then have another one with multiple tasks glued into one (because "such a great idea" to have a kata asking you to add an iterator to an existing class when we have a few katas specifically about extending a class, and a few katas specifically about iterators).

an Object value is absolutely not an Array value

The easiest (and the most reasonable?) way to solve the task is to "convert" the object into a keys/entries array, and iterate over it, so...

More kata combine functionality from other kata. Let's agree to disagree here.

A key-value pair absolutely is a value. But an Object value is absolutely not an Array value. There's not a worth 2 kyu difference, but there is a difference. If you don't want to understand this, let's agree to disagree here.

but the task in this kata specifically is extending Object.prototype with an iterator

• We already have katas asking you to extend a built-in type
• This is no different from defining a normal function (in fact the whole extending business comes down to assigning a normal function to some type's prototype)
• Extending a built-in type is a bad practice

Also, there are no array values, there only are object key/value-pairs

I don't see how key-value pair is not a value (but this note is pointless in this discussion).

( dammit. it did post. )

( deleted )

There may be existing kata that ask to implement an iterator/generator, but the task in this kata specifically is extending Object.prototype with an iterator. If you consider this kata a duplicate, please point out what you consider to be the original(s). Also, there are no array values, there only are object key/value-pairs.

I still think this kata deserves its own lease on life. Higher ratings would help there however, and that means much better testing to start with, otherwise it may deserve a life but throw it away itself. ( My own rating still is Not Much because of the wholly inadequate testing. )

Even then we already have katas asking you to implement an iterator/generator in JS, so I don't see a point in another kata which asks you to simply yield the array values.

I disagree.

There are more kata that are solveable with the same code, but where the simpler of the two is also solveable with simpler code. That does not make them duplicates. In that case, the reverse should be true as well, and it isn't here.

Plain objects and also objects from Object are not iterable ( using for .. of ). We can bypass this by circumvent iterator to the object prototype with a custom iterator.

Constructed Objects and "plain" Objects are indistinguisable. Possibly you mean "Objects constructed from an object literal"?

"Bypassing" seems to be the wrong term here, and what you mean by "circumvent" is entirely unclear.

Also, it is preferable to specify expected values instead of relying on an example, which asks us to read your mind ( granted, your thought are pretty clear here, but the general principle holds ).

May I suggest "
Most Objects ( excluding Arrays and the like here ) are .. (). We can rectify this for our purposes by extending the Object prototype with a custom iterator.

Our iterator should produce successive ( in insertion order ) values of [ key, value ].
" ?

All of the random tests have objects of size 1. Is this intentional, or was that 1 meant for allowNested?

( This is why you await confirmation the issue is actually solved before closing them. )

( Your kata idea has nothing to do with it being a duplicate or not though. )

The kata is still a duplicate. The fact that you've solved both of your katas with the same code only proves the point.

I corrected and added random tests

I changed the discription