> Promises/A has been ported to Ruby, with basically the same API… This is, to me, the core of the problem. > The Promises/A spec from CommonJS defines Promis

> Promises/A has been ported to Ruby, with basically the same API… This is, to me, the core of the problem. > The Promises/A spec from CommonJS defines Promise.then as taking three (optional) callbacks: fulfilledHandler, errorHandler, and progressHandler. The code above is passing two of them at once. Shoehorning things from different realms (e.g desperately trying to write JS in Ruby or vice-versa) is not a good idea. Instead of either: db.select_one(sql, thingid) .then((proc {|rowset| rowset[0]['foo'}), (proc {|err| log_error(err)})) or: db.select_one(sql, thingid) .then {|rowset| rowset[0]['foo'} .then(nil) {|err| log_error(err)} Why not do: db.select_one(sql, thingid) .then {|rowset| rowset[0]['foo'} .else {|err| log_error(err)} .each {|whatever| the_progress(callback_is)} Also, method(:log_error) will happily turn the method into a proc. This last case is actually extremely important. Contrary to what the author claims, functions and methods are first class in Ruby. The problem is that in Ruby's grammar an identifier without parentheses is a method call if that identifier does not resolve to a variable. Therefore, you cannot refer to an existing function by its name, merely because it would resolve to a call. Therefore the difference between those is purely syntactic: Python Ruby foo method(:foo) foo() foo Also, this[0] explains how &:to_i works, which can be leveraged with great success, should one implement the promise class in a sufficiently idiomatic way (turning the above log_error reference into &:log_error) [0]: http://ablogaboutcode.com/2012/01/04/the-ampersand-operator-in-ruby/ http://ablogaboutcode.com/2012/01/04/the-ampersand-operator-...