That's because (in Ruby and many other languages) you can use an integer to get to the n-th charactetr in a String just as you can get the n-th element of an Array.
You can think of a String as an ordered list of charscters (technically code points, but thats another story).

why don't we need to turn em into arrays ?

Ahh that makes sense, thanks!

Neat!

What about conditions for gandicap? I should be -2 < gandicap < +26. This solution doesn't consider all kata's conditions

So cool!

Well, I mean, the instructions say to return a variable 'l', and it's part of the code that's automatically put into the solution. I know my comment seems pedantic, but that wasn't my intention. I really do think this is the best answer, just that it doesn't follow that specific instruction.

Wouldn't want to run this simple categorisation against a database of millions! Object instantiation for each comparison of 2 intgers?

That may be better for more expensive calculations, but the beauty of this design is that it mostly doesn't matter. That change could be entirely internal to the class, with no change to the external interface. So... we don't have to make any decision about it until we've tested the performance.

I know this is done this way because the comparison is super basic... But what if "category" was expensive to calculate? Shouldn't it be stored inside the object? Created in initialize and refreshed everytime an attribute's setter is called.