Your comment with this bit of code was enough for me to get a working solution:

a = {id: 1}
b = {id: 1, name: 'example'}

I suspect you're right that some of the language is confusing, but I don't have any specific suggestions to improve it. Maybe you could update your last example to look like this:

processor.process_items([{value: 2}, {value: 3}]) do |item|
  # will only process {value: 2},
end

processor.process_items([{value: 2, name:'example'}, {value: 6}]) do |item|
  # will only process {value: 6} since {value: 2} has already been processed
end

That pretty clearly illustrates the implied equality between different hash instances with the same values of the 'identify' key. It also gives a specific example to plug neatly into the users' test fixures.

My original code passed all of my own test fixtures (which were based on your examples), but it definitely would've failed if I had built a test based on this one.

I think I'm going to stop using the word reference, especially since in ruby its a bit confusing since the following would work:

a = {id: 1}
b = {id: 1}

a == b # in ruby this would be true, in many other languages (ie JavaScript) it would be false since they don't point to the same memory reference

When I say "reference" I meant that the typical way of determining if two items are the same (they point to the same reference). For example:

a = {id: 1}
b = {id: 1, name: 'example'}

# without identity being called they would be compared like so:
a == b # false

# with identity(:id) called they would be compared like so:
a[:id] == b[:id] # true

Thanks but I still don't get it. I think you could clarify "If this method is not called then the item/hash reference will be used instead. " I understood "reference" as an object_id while you meant actual key-value pair.
But I still get the same error and I think it's related to processed_items not filtering new items properly. I don't know what I miss in kata description.

I think this is a great example of pushing the limits of what kata can be used for. It would be great to see other fun kata like this, enough that it would be worth having a separate section for them.

OK, I added a remark about "submit to get an expected pair" to the description. Hope that helps others. Happy hacking!

Well, I wrote "clean-room" because you have to "copy" something without being able to look what you have to copy, you only know the expected outcome. And I think MS-DOS was NOT a clean-room development, sorry about that, wrong memory.

But it's definitively a game! So I added that to the title of the Kata.

Or do you think codewars should add a "game"-section? I was just too tempted to test the limits of the codewars Kata-system, and I was pleasantly surprised about the possibilities...

This isn't about getting something to work without knowing what happens inside, tho, this is about defining what happens inside without knowing how it's expected to work. I doubt that's how anything was developed.

It should probably be added to the description that the expected value will be given at each failed attempt. Generally, a submission at Codewars is a piece of code that you expect solve the problem. I don't think anyone here is naturally inclined to submit a stab in the dark just to find the pattern, unless this is specified.

Thanks for the gist. I found the issue with your code and added a new test case to help identify the issue easier. Let me know if that helps.

Got same error

Yes, that's black-box / clean-room development! It just has to work, without really knowing what happens inside. You get the feeling of how they did the initial MS-DOS ;)

You know that the input is an array of numbers representing 6-side dices and the output is an integer. Every time you submit your solution, it will tell you what the correct number would have been...

There is an example implementation, codewars won't let you publish a kata without a solution that passes all of the tests. "can't convert String to Integer" isn't anywhere in my tests. Maybe you can post your solution in a gist (so that it can be removed later) and then I can take a look at it?

Yeah the class was originally called ItemProcessor and I renamed it, but didn't update the test messages. Thanks for pointing that out. Its fixed now.