- Video (YouTube): https://youtu.be/zvQ_K2Edu-Y
- Slides (Speakerdeck): https://speakerdeck.com/keithrbennett/functional-programming-in-ruby-with-lambdas-1e80e559-90bd-4e73-acef-86e84ff209f3
Some practical application of these concepts can be seen in my "Writing a Command Line Application in Ruby" presentation at Paris.rb Conf in 2018 (https://www.youtube.com/watch?v=zMzzKOecvaA).
The slides use Jetbrains Mono font with ligatures. If you see unfamiliar characters, they are ligatures, which are textual representations of special character sequences. Examples are ->, >=, <=, <>, ||=. (Explained while answering Bryan's question at 11:45.)
3:28 (Slide #13) I said "...all of our coding is at the method level". I should have left it at "most". Coding is also done in lambdas, class definitions (constant definitions, calls to class methods such as attr_accessor
), etc.
04:30 (13) I don't remember Matz' exact words, and may be embellishing, but I did not make this up! :)
By the way, it is possible to define a method inside another method, but that method becomes a regular instance method and is not nested or scoped in any way.
5:54 (15) - I said that the number of possible paths of interaction for a 20-method class was 390, but I should have said 380 (20 * (20 - 1)).
13:14 (21) - There are several instances in the presentation where a trivially simple example is used to illustrate usage, etc., but where in that particular case the use of a lambda would be overkill. The "Lambdas and Threads" slide is one of them. For example, it would be fine to use { `uptime` }
in the thread code instead of the lambda.
16:10 (22) - I checked, and lambda
is a method in the Kernel
module, and not a language keyword.
21:46 (28) - I said "Nicole?" but I should have said "Miriam?". Sorry, Nicole and Miriam!
30:20 (31) - I was unclear about the testability of lambdas. The situation where they cannot be tested is when they are local to a method. If they are exposed to be accessible to the test code (e.g. returned by a method or contained in a class constant) then they can be tested. So when I said "if something does need to be testable by itself then it should be a method" was not correct. (Nicole, I apologize for this, I realize that one of your comments later on was based on this misrepresentation.)
38:20 (37) - Regarding Bryan's question "are lambdas hoisted?", I should have pointed out that it's not objects that are hoisted, it's variables. For example, iff a method contains this:
def foo
if false
my_lambda = -> { } # this would behave the same if it were: my_lambda = 333
end
p my_lambda
end
...then calling foo
will result in the output nil
. However, it really doesn't matter what type of object is assigned, since hoisting is done on variables, not the values (or lack thereof) they contain.
41:36 (41) More about lambdas vs. code blocks for passing filters...I did not explain that one of the requirements was to support unfiltered lists. Given that, the code needs a way not to filter messages. In the case of the lambda parameter, we can specify a default argument, a lambda that always returns true. If the caller omits this last parameter, then messages will not be filtered.
In the code that uses code blocks, we can check block_given?
, assuming that not passing a block means that no filtering is wanted.