Done

That was interesting :)

Thanks for the kata. I have learned something new. :)
I think you should mention that in the kata instructions. It is not obvious requirement and I had to check in discussion why may code didn't pass the last test.
Regards,
Bozhkov

I think this is a good change. However, might I suggest that instead of #identify only taking a 'name' parameter and then trying to determine how to use it, why not have #identify take a block which yields the item and returns the identifying key. You could leave the original signature of #identify as a shortcut for hash access.

# still provide hash access shortcut
processor.identify(:id)

 # arbitrary key access or calculation
processor.identify { |job| job.id }
processor.identify { |user| user.email.downcase }

Both ways of calling identify should still respect the duplication restrictions. The return value from the block form would be the basis for determining that it is a duplicate or not.

Since this whole kata is a large exercise in playing with blocks, I think this is a more fun than simply calling #send on user input.

Haha. Well, I'd appreciate the joke, at least! :D

Maybe the kata should be called "when the thrush knocks" then.

@soapie: It's actually closer to something called the "Thrush combinator" or "T combinator."

Reminds me of the clojure thread macro which behaves in a similar way including reversing the order of the functions. I don't think there's anything wrong with the kata but the name might be slightly misleading since it isn't so much to do with actually composing functions.

So, I'm making two separate points, one which is technical and the other which is more aesthetic. The technical argument is that it doesn't make sense to have the input as the first argument. It's the last piece of information you're going to know and almost entirely defeats the purpose of the compose function, per my comment above.

The aesthetic argument is about the ordering of the function arguments in compose. This really is a matter of convention, but in JavaScript and other languages that don't use a RPN-style syntax, you write things like

secondGuy(firstGuy(20));

and not

20 firstGuy secondGuy

That's not to say it's wrong, it's only to say that it seems inconsistent WRT how the rest of the language works. I'd expect the arguments to the compose function to follow the order as I would write them in code rather than the order in which JavaScript would execute them.

That is, I'd expect this to always hold:

compose(secondGuy, firstGuy)(x) === secondGuy(firstGuy(x));

So, let's say we have a compose method that works the way I'm thinking:

var addOne = function(n) { return n + 1; }
var square = function(n) { return n * n; }

var both = compose(square, addOne);

both(20);
[1,2,3,4].map(both);
[10,20,30,40].map(both);

I see no good reason not to do it this way. Indeed, to do it any other ways seems to defeat the purpose of the compose function. If I had the input value, I'd just call

square(addOne(x));

rather than

compose(x, addOne, square);

A compose method only really has value when you want to talk about the functions per se as opposed to the functions absent any particular inputs. In fact, forcing the input to be given prevents you from passing the composition to other functions that expect functions as input, e.g., my use of "map" in the examples above.

if we call it with

compose( x, f, g )

using

x = 5
f = double
g = add one

then

f( g( x ) ) = f( g( 5 ) ) = f( 6 ) = 12
and g( f( x ) ) = g( f( 5 ) ) = g( 10 ) = 11

so it DOES g( f( x ) ) - but I do think it's OK, at least it makes sens to me. It's like passing the value from function to function, left to right. We used
f ° g in our maths classes, IIRC.

I just made another example, is it clear enough? if not please let me now

oystercar ☃ ~
10001 ◯ : coffee
coffee> str = "The quick brown fox jumped over the lazy dog."
'The quick brown fox jumped over the lazy dog.'
coffee> str[1..]
'he quick brown fox jumped over the lazy dog.'
coffee> str[5..]
'uick brown fox jumped over the lazy dog.'
coffee> str[20..]
'jumped over the lazy dog.'
coffee> ending = 25
25
coffee> str[ending..]
'd over the lazy dog.'
coffee> ending = 3
3
coffee> str[-ending..]
'og.'

oystercar ☃ ~ 10001 ◯ : coffee
coffee> str = "The quick brown fox jumped over the lazy dog."
'The quick brown fox jumped over the lazy dog.'
coffee> str[1..]
'he quick brown fox jumped over the lazy dog.'
coffee> str[5..]
'uick brown fox jumped over the lazy dog.'
coffee> str[20..]
'jumped over the lazy dog.'
coffee> ending = 25
25
coffee> str[ending..]
'd over the lazy dog.'
coffee> ending = 3
3
coffee> str[-ending..]
'og.'

Hope that clears it up! :)

What does 'kihon' mean? 'walking'?