Thanks for the feedback, I'll fix it up a little :-)

Just to be clear, my previous post was in regards to scrabbledude's comment, not boatmeme's. That would have seemed a bit arrogant :P

Of course! I absolutely agree with that statement.

If the constraint hadn't been defined I would have done it with an algo. However, with clearly defined limits like that (which you typically have in computer science problems) I think a lookup table is a good solution. The solution is fast, the code is easy to understand and it's fast to write.

I don't think it's a bad thing within the confines of the problem since it was clearly defined as a limit.

Without that limit it becomes unwieldy and a pain to ensure that it remains accurate if it's in an active code base.

I don't see why a lookup table is a bad thing though.

Well, I've been assuming that a big part of this site is helping folks get better at the various languages. Beginners at anything are a bit like children: they absorb a million details, said and unsaid, and translate them into often-incorrect rules,. For example, when a child gets corrected for saying "I brang the water to Mom" and is exasperated when corrected, arguing "But if we say ring/rang why don't we say bring/brang?!"

You can call that pedantry if you want, but what you're doing by violating the naming conventions of a language is teaching beginners another set of conventions, whether you like it or not. I personally think that's a disservice to students.

To give you an example of how subtle this effect is, here is something I actually witnessed while teaching someone the basics of programming. We're covering variables and variable assignment in Ruby and they see

my_name = "Jesse"
my_age = 29
my_city = "San Francisco, CA"

puts "Hello!  My name is #{my_name}.  I'm #{my_age} years old and live in #{my_city}."

Later, I see code like this:

my_counter = 0
while my_counter < array.length
  puts array[my_counter]
end

I see the code and remark, "Normally we give counter variables simple names like i, j, etc." They reply, "Oh, I thought the name of every variable had to start with my_! You mean it can be anything?"

That's how beginners work, so every aspect of your code is going to be absorbed in that way.

This seems to be the same place that @leemour got caught up on. His gist shows that he was passing the key value into the process_items block instead of the entire hash object. You seem to be passing the id into the block instead of the entire item/hash.

One of the solved solutions also seems to be passing a new hash with just the id value as its only key/value, instead of the original hash - so they too are also confused. I figured the description would be clear enough because its called process_items and takes and the block argument is called item. So item should always be one of the items passed into the process_items method. Some of the examples show that the item being passed in is a hash. Also the entire point of the class is to be able to process the items passed in, not their ids. The ids are just supposed to be used as a way of determining if an item has already been processed without having to depend on the hash instances actually being the same reference. I think maybe the initial examples where only ids are used and not hashes are what is confusing everyone. Maybe the identity method description is confusing too (any tips on how to make it less confusing?)

I updated one of the examples to try to indicate what exactly "item" is when its passed in.

First I thought "what a cheater", but after a good night's sleep I now know better, thanks for all your suggestions ;)

I tried to push the difficulty further - if it gets hard enough to crack, people will perhaps try to solve the puzzle, no? Are there other possibilities to have the function as a string?

I just left a small hint about the "real" game, as I feel bad to copy and change the name.

For the out-of-scope variable, I think if the test-fixtures are not visible, that's already enough - what do you think?