Keyword Args — the killer Ruby feature you aren't using
Howe, Guyren G.
Write clearer code more easily. Write functions that are more composable and flexible. Ruby 2.0's KWArgs feature isn't just an easier way to write functions that take keyword arguments; KWArgs turn Ruby into a lean, mean Hash processing machine. In this talk, you'll learn the details of how to write the next generation of Ruby code. Code that is easier to read, easier to write, more flexible and easier to change, all based on this one simple Ruby feature.
 All right, it's five past, so I'm going to get started. But before I go on to the content of the talk, I feel like there's something I have to address which is the election. This is very important. The District of Columbia has sent a petition or is about to send a petition to the Congress asking to be made a state. This will make the District of Columbia the 51st American state. But I think we're missing an opportunity here. I think what we need to do is pick two more places, Guam and somewhere. Puerto Rico, make them states because then we'll have 53 states which is a prime number and America will be a nation indivisible. Thank you. Thank you. My wife said I should open with a joke. That's the only joke you're getting, though. Who here is using keyword arguments in their Ruby code? Who here would say they're using keyword arguments enthusiastically in their Ruby code? Like in most places. With any luck, this will be the most useful presentation or one of that you see at this conference because if I do my job right here, you will leave here and change the way you write your Ruby code in a significant way. So I say the keyword arguments is a killer Ruby feature you're not really using. Who am I? I've been a software developer for 20 years. A Ruby developer for 10. I was in the room when Twitter was publicly announced for the first time in Austin, I believe. It was about when I started using it. I taught at a boot camp for a Ruby web serving framework. I've been told if I mentioned this Ruby web serving framework at this Ruby conference which isn't about the Ruby web serving framework, that Burley men will come in and drag me out. So I taught at a boot camp for that for about a year and I do consulting around that and postgres and I decided to start work because people don't use postgres and databases well enough in this community. I'm going to work on a book about that. Here's what we're going to talk about. We're going to make it clear what keyword arguments are and what they do, how they make your code clearer which might seem simple and obvious but there's a little more to say about that than you might think. And then I'm going to talk about how keyword arguments can make the functions that you're writing more flexible and more functional in a couple of different senses. So let's start with how keyword args work. Here's an example of a method declaration in Ruby that has every possible way or every kind of argument. So there's a positional required argument, a positional optional argument, positional argument splat, a required keyword argument, an optional keyword argument, a keyword arg splat which it turns out is super interesting and the block thing. Now the clever folks who've implemented this feature have done a great job of making it nice and intuitive. So you can call a keyword args function like that. You can take a hash and then call it like that. If you're using something from like a millennia ago in internet time, you can call it like that. This is a nice feature that I don't believe you can do with positional args. A keyword arg, an optional keyword arg can refer to an earlier keyword argument for its default value which is really nice. And you can splat hashes into other hashes. So that's all very nice and intuitive and simple and fairly easy to use. A couple of caveats, you have to put the positional args all before the keyword args and because it does this business of interpolating hashes into the keyword args, if your last positional arg is a hash, Ruby can get confused. Yes, we're getting nodding over here. So I think it seems obvious that the main thing that you're likely to get out of keyword args is that that is clearer. Here is a method that you might call from the Ruby standard library. And unless you've worked with this function very recently, I defy anybody to tell me what all these arguments are. They are in fact the server you want to hit and it's port. The proxy server you want to use, the port for the proxy server and the last two arguments are no, they're in fact the username and password for the proxy server. That's what's talking about how Ruby is a human-centered language and I'm afraid this is bad. We can do better now with keyword arguments. So let's imagine a different world in which the Ruby standard library was rewritten around keyword arguments and what this method call might look like. Now if you may have experimented with using keyword args and found yourself writing something like that and gone, it's sort of better but there's just ASCII salad up here, you can't tell at a glance what's a keyword and what's an argument. It's sort of maybe a bit better but not really. And fair enough. The problem I think is this book. Now let me be clear, I am an enormous admirer of this book. If you have to write any kind of technical book, you could do better than slavishly copy this book in every way you possibly can. Furthermore, I don't think we would be here today if it wasn't for this book. We, well, Matt's wouldn't be here at all and the rest of us would be at a Java conference or something awful. Not only did it, was it responsible for teaching us all to use Ruby and showing the world what an amazing language it is but it established a lot of the conventions that we all use which is one of the delights of using Ruby. You can go and read somebody else's code and because we all use the conventions that are established in this book about how we write identifiers and blocks and all the rest of it, it's established a really nice sort of set of conventions. However, this book was written something like 15 years ago and I don't think they have a version that covers the keyword args feature yet. And in any event, I think the conventions we've all got around formatting our code come from this version of this book. So in some ways, if we are to move on and use these new features, we have to be prepared to move past that book. So if you're going to use keyword arguments and there's more than like two of them, I think you should be prepared to write your Ruby code like this. People, many people have suggested this to have like kind of horrified but I think it's, it is quite clear. In fact, I can't imagine a way of making what you're saying here much clearer. All right. I defy anyone to tell me that the bottom one is better in any way. So I've been going around, since I started really digging into keyword args, I've been going around saying this to people and they're all like, yeah, okay, sure, it's, you know, it's a bit clearer. But I have to, to make it clear, I have to change the way I work and I like the way I work and if I hire new people or show my code to someone else, they're not really going to follow it. And you know, I kind of really like my buggy whip. And it's fair enough. Like that's not enough reason to go away from here and start changing everything about the way you write code, right? But there's one advantage you can have, which is that it's clearer. There is a clear advantage though to keyword args, which is that they are strictly more flexible than positional arguments. The first and most obvious way is that the optional arguments are all actually optional. So with positional optional arguments, you have to supply them left to right. I can't just give the third one. But with keyword arguments, I can pass in whichever ones I happen to need for the job at hand. Keyword argument functions are strictly more flexible. Let's look at an example of what that might look like. Let's say I'm using some sort of a Ruby web serving framework. And I'm calling a controller functions, calling a rendering function. And then later on, I decide, well, I've got a new controller now and it needs to be able to control what the headers look like. Well, I can add a headers argument to my function, now switching to the new style here in the function definition as well. And now I can pass that in. And later on, we decide, well, we'd like to be able to control the striping in the table, say. So now I can add a stripes argument and pass that in. Now notice that one controller is passing in one optional argument, the other controller is passing in a different optional argument. And it's all nice and clear and easy to follow. Versus, if you tried to do the moral equivalent of that with a positional argument function, you'd do something probably like that. And then you'd call it something like that. And that's obviously harder to follow, but pass two or three optional arguments, you're just not going to bother, right? You're going to switch to some sort of object-oriented solution, which is going to be more complicated. You're going to have an initializer and then state that you've got a track. This lets you do things sticking to functions in Ruby. And that's sort of where the industry is going, right? Somewhat away from object-oriented bureaucracies and more towards a functional style of programming. And much of my message here today is that keyword args invite you to use Ruby in a more functional sort of style. In fact, I see nothing wrong with having lots of parameters, lots of optional parameters. It'll be a bit long, maybe, but not hard to follow at all, I don't think. If this is a function that does a single thing and there's just a variety of different options for how it should do it, I think this is fine. Why not? So keyword args are more flexible and they allow you to rewrite code in one place without having to change all the users more easily than if you'd used positional arguments. There's a term for that, it's called loose coupling. And that ability to have all the sort of assumptions up the top and to change them as you're going, as you need, it's known as dependency injection, and both of these things are better if you write your functions using keyword arguments. In fact, let's imagine that we're back in like 2005 and you're working for a small company that's developing some sort of a Ruby web serving framework. But you have Ruby 2.3 available to you and they say, we need a quick and dirty solution for an ORM, right? I want something where I can just sort of throw a where clause and an order by clause and it'll generate SQL for me. If you had Ruby 2.3 available rather than the object oriented bureaucracy that you might have done, you could do write a function with a signature much like that and if you think about turning that into an SQL function, expression, it's cake, right? So there's a lot of the time when you would, until now, have written object oriented classes and all that, this feature invites you to adopt a more functional sort of style. So I mentioned the keyword argsplat as being super interesting. So let's start out with the simpler uses of it. Say you have a salary calculation function and then someone comes to you and says, we'd like to be able to override the arguments of that function on a per user basis. So there's a default set of behaviors and certain users get it different. So what you do is you add a JSON field to your user table and you just do that. So what's really nice is that you can treat a hash in Ruby now as a kind of canned partial function or whole function. There's a term in functional programming called curring and Ruby has a curring feature but you can actually treat hashes now as something along those same sort of lines. And if someone says to you, okay, well, I want, they'll be right on a company basis and then override that on a per user basis if I want, that's also cake. You just add a JSON field to company and you're done and it's functional. It's more functional in a couple of different senses, right? You're invited to do a functional solution and it's easier and quicker to do. So I hope that's enough to convince you that you might like to leave here and go home and maybe start writing your Ruby a somewhat different way and writing much of it or nearly all of it around keyword arguments because they're just better. Let me now illustrate something a little sort of wacky and crazy that I've discovered. I've not seen this, anybody else talk about this although I'm sure somebody else has discovered it but it's a fun sort of interesting thing to look at to end this talk. I call it the context funnel. So here's what it looks like when you use it and it just involves putting this star, C for context, splat at the end of your functions. In fact, what you do is in all the functions that you're writing and calling, not framework functions that you can't control, you always receive this splat and you always pass it on. So let's see what that lets you do. Let's say I'm using a Ruby web serving framework and I'm calling a render table function and maybe it looks like this. Now since this is the first function I've called from my code, I'm adding the star, C and in other functions that I call that I've written, I pass it on. Then maybe render row looks something like this. So the parts of my code that I've written in this case are view. I pass that C on to again and maybe my view starts out looking something like this. So I've got this sort of call chain that starts up at the controller with render table and ends with that view. Let's say now in some cases I want to be able to format that last name differently. So this is a sort of moral equivalent of the keyword args for a view, I think. So I'm allowing you to set a value if you want and if not, I'm giving it a default behavior which is do the same thing we did before, right? Now look what I can do. Back at the top of that call chain without changing anything in between, I can pass in this argument and it gets passed down by all the functions in between because they didn't understand it and they didn't care about it and it winds up down at the view. This is really interesting to work with particularly as you're sort of exploring developing code, I was doing something or I was parsing some complicated EDI code and I was writing all these functions and they were digging down inside this and then I realized down here I needed some value I had from some earlier point in the call chain and without having to rewrite everything in between I was able to change that. So this is an example of where a functional programming style and keyword args give you code that's more flexible. Anyway, that was just a little crazy thing I discovered that I'll put a post on my blog about describing that in more detail. Nearly out of time but in summary keyword args are clearer. They are more functional in a couple of different senses. They invite you to write a more functional, simpler style of code much of the time rather than an object-oriented bureaucracy. And they are more flexible. Thank you. Thank you.
 All right, it's five past, so I'm going to get started.  But before I go on to the content of the talk, I feel like there's something I have to address  which is the election.  This is very important.  The District of Columbia has sent a petition or is about to send a petition to the Congress  asking to be made a state.  This will make the District of Columbia the 51st American state.  But I think we're missing an opportunity here.  I think what we need to do is pick two more places, Guam and somewhere.  Puerto Rico, make them states because then we'll have 53 states which is a prime number  and America will be a nation indivisible.  Thank you.  Thank you.  My wife said I should open with a joke.  That's the only joke you're getting, though.  Who here is using keyword arguments in their Ruby code?  Who here would say they're using keyword arguments enthusiastically in their Ruby code?  Like in most places.  With any luck, this will be the most useful presentation or one of that you see at this  conference because if I do my job right here, you will leave here and change the way you  write your Ruby code in a significant way.  So I say the keyword arguments is a killer Ruby feature you're not really using.  Who am I?  I've been a software developer for 20 years.  A Ruby developer for 10.  I was in the room when Twitter was publicly announced for the first time in Austin, I  believe.  It was about when I started using it.  I taught at a boot camp for a Ruby web serving framework.  I've been told if I mentioned this Ruby web serving framework at this Ruby conference  which isn't about the Ruby web serving framework, that Burley men will come in and drag me out.  So I taught at a boot camp for that for about a year and I do consulting around that and  postgres and I decided to start work because people don't use postgres and databases well  enough in this community.  I'm going to work on a book about that.  Here's what we're going to talk about.  We're going to make it clear what keyword arguments are and what they do, how they make your code  clearer which might seem simple and obvious but there's a little more to say about that  than you might think.  And then I'm going to talk about how keyword arguments can make the functions that you're  writing more flexible and more functional in a couple of different senses.  So let's start with how keyword args work.  Here's an example of a method declaration in Ruby that has every possible way or every  kind of argument.  So there's a positional required argument, a positional optional argument, positional  argument splat, a required keyword argument, an optional keyword argument, a keyword arg  splat which it turns out is super interesting and the block thing.  Now the clever folks who've implemented this feature have done a great job of making it  nice and intuitive.  So you can call a keyword args function like that.  You can take a hash and then call it like that.  If you're using something from like a millennia ago in internet time, you can call it like  that.  This is a nice feature that I don't believe you can do with positional args.  A keyword arg, an optional keyword arg can refer to an earlier keyword argument for its  default value which is really nice.  And you can splat hashes into other hashes.  So that's all very nice and intuitive and simple and fairly easy to use.  A couple of caveats, you have to put the positional args all before the keyword args and because  it does this business of interpolating hashes into the keyword args, if your last positional  arg is a hash, Ruby can get confused.  Yes, we're getting nodding over here.  So I think it seems obvious that the main thing that you're likely to get out of keyword  args is that that is clearer.  Here is a method that you might call from the Ruby standard library.  And unless you've worked with this function very recently, I defy anybody to tell me what  all these arguments are.  They are in fact the server you want to hit and it's port.  The proxy server you want to use, the port for the proxy server and the last two arguments  are no, they're in fact the username and password for the proxy server.  That's what's talking about how Ruby is a human-centered language and I'm afraid this  is bad.  We can do better now with keyword arguments.  So let's imagine a different world in which the Ruby standard library was rewritten around  keyword arguments and what this method call might look like.  Now if you may have experimented with using keyword args and found yourself writing something  like that and gone, it's sort of better but there's just ASCII salad up here, you can't  tell at a glance what's a keyword and what's an argument.  It's sort of maybe a bit better but not really.  And fair enough.  The problem I think is this book.  Now let me be clear, I am an enormous admirer of this book.  If you have to write any kind of technical book, you could do better than slavishly copy  this book in every way you possibly can.  Furthermore, I don't think we would be here today if it wasn't for this book.  We, well, Matt's wouldn't be here at all and the rest of us would be at a Java conference  or something awful.  Not only did it, was it responsible for teaching us all to use Ruby and showing the world what  an amazing language it is but it established a lot of the conventions that we all use which  is one of the delights of using Ruby.  You can go and read somebody else's code and because we all use the conventions that  are established in this book about how we write identifiers and blocks and all the rest  of it, it's established a really nice sort of set of conventions.  However, this book was written something like 15 years ago and I don't think they have a  version that covers the keyword args feature yet.  And in any event, I think the conventions we've all got around formatting our code come  from this version of this book.  So in some ways, if we are to move on and use these new features, we have to be prepared  to move past that book.  So if you're going to use keyword arguments and there's more than like two of them, I  think you should be prepared to write your Ruby code like this.  People, many people have suggested this to have like kind of horrified but I think it's,  it is quite clear.  In fact, I can't imagine a way of making what you're saying here much clearer.  All right.  I defy anyone to tell me that the bottom one is better in any way.  So I've been going around, since I started really digging into keyword args, I've been  going around saying this to people and they're all like, yeah, okay, sure, it's, you know,  it's a bit clearer.  But I have to, to make it clear, I have to change the way I work and I like the way I  work and if I hire new people or show my code to someone else, they're not really going  to follow it.  And you know, I kind of really like my buggy whip.  And it's fair enough.  Like that's not enough reason to go away from here and start changing everything about the  way you write code, right?  But there's one advantage you can have, which is that it's clearer.  There is a clear advantage though to keyword args, which is that they are strictly more  flexible than positional arguments.  The first and most obvious way is that the optional arguments are all actually optional.  So with positional optional arguments, you have to supply them left to right.  I can't just give the third one.  But with keyword arguments, I can pass in whichever ones I happen to need for the job  at hand.  Keyword argument functions are strictly more flexible.  Let's look at an example of what that might look like.  Let's say I'm using some sort of a Ruby web serving framework.  And I'm calling a controller functions, calling a rendering function.  And then later on, I decide, well, I've got a new controller now and it needs to be able  to control what the headers look like.  Well, I can add a headers argument to my function, now switching to the new style here in the  function definition as well.  And now I can pass that in.  And later on, we decide, well, we'd like to be able to control the striping in the table,  say.  So now I can add a stripes argument and pass that in.  Now notice that one controller is passing in one optional argument, the other controller  is passing in a different optional argument.  And it's all nice and clear and easy to follow.  Versus, if you tried to do the moral equivalent of that with a positional argument function,  you'd do something probably like that.  And then you'd call it something like that.  And that's obviously harder to follow, but pass two or three optional arguments, you're  just not going to bother, right?  You're going to switch to some sort of object-oriented solution, which is going to be more complicated.  You're going to have an initializer and then state that you've got a track.  This lets you do things sticking to functions in Ruby.  And that's sort of where the industry is going, right?  Somewhat away from object-oriented bureaucracies and more towards a functional style of programming.  And much of my message here today is that keyword args invite you to use Ruby in a more  functional sort of style.  In fact, I see nothing wrong with having lots of parameters, lots of optional parameters.  It'll be a bit long, maybe, but not hard to follow at all, I don't think.  If this is a function that does a single thing and there's just a variety of different options  for how it should do it, I think this is fine.  Why not?  So keyword args are more flexible and they allow you to rewrite code in one place without  having to change all the users more easily than if you'd used positional arguments.  There's a term for that, it's called loose coupling.  And that ability to have all the sort of assumptions up the top and to change them as you're going,  as you need, it's known as dependency injection, and both of these things are better if you  write your functions using keyword arguments.  In fact, let's imagine that we're back in like 2005 and you're working for a small company  that's developing some sort of a Ruby web serving framework.  But you have Ruby 2.3 available to you and they say, we need a quick and dirty solution  for an ORM, right?  I want something where I can just sort of throw a where clause and an order by clause  and it'll generate SQL for me.  If you had Ruby 2.3 available rather than the object oriented bureaucracy that you might  have done, you could do write a function with a signature much like that and if you think  about turning that into an SQL function, expression, it's cake, right?  So there's a lot of the time when you would, until now, have written object oriented classes  and all that, this feature invites you to adopt a more functional sort of style.  So I mentioned the keyword argsplat as being super interesting.  So let's start out with the simpler uses of it.  Say you have a salary calculation function and then someone comes to you and says, we'd  like to be able to override the arguments of that function on a per user basis.  So there's a default set of behaviors and certain users get it different.  So what you do is you add a JSON field to your user table and you just do that.  So what's really nice is that you can treat a hash in Ruby now as a kind of canned partial  function or whole function.  There's a term in functional programming called curring and Ruby has a curring feature but  you can actually treat hashes now as something along those same sort of lines.  And if someone says to you, okay, well, I want, they'll be right on a company basis and then  override that on a per user basis if I want, that's also cake.  You just add a JSON field to company and you're done and it's functional.  It's more functional in a couple of different senses, right?  You're invited to do a functional solution and it's easier and quicker to do.  So I hope that's enough to convince you that you might like to leave here and go home and  maybe start writing your Ruby a somewhat different way and writing much of it or nearly all of  it around keyword arguments because they're just better.  Let me now illustrate something a little sort of wacky and crazy that I've discovered.  I've not seen this, anybody else talk about this although I'm sure somebody else has discovered  it but it's a fun sort of interesting thing to look at to end this talk.  I call it the context funnel.  So here's what it looks like when you use it and it just involves putting this star,  C for context, splat at the end of your functions.  In fact, what you do is in all the functions that you're writing and calling, not framework  functions that you can't control, you always receive this splat and you always pass it  on.  So let's see what that lets you do.  Let's say I'm using a Ruby web serving framework and I'm calling a render table function and  maybe it looks like this.  Now since this is the first function I've called from my code, I'm adding the star,  C and in other functions that I call that I've written, I pass it on.  Then maybe render row looks something like this.  So the parts of my code that I've written in this case are view.  I pass that C on to again and maybe my view starts out looking something like this.  So I've got this sort of call chain that starts up at the controller with render table and  ends with that view.  Let's say now in some cases I want to be able to format that last name differently.  So this is a sort of moral equivalent of the keyword args for a view, I think.  So I'm allowing you to set a value if you want and if not, I'm giving it a default  behavior which is do the same thing we did before, right?  Now look what I can do.  Back at the top of that call chain without changing anything in between, I can pass in  this argument and it gets passed down by all the functions in between because they didn't  understand it and they didn't care about it and it winds up down at the view.  This is really interesting to work with particularly as you're sort of exploring developing code,  I was doing something or I was parsing some complicated EDI code and I was writing all  these functions and they were digging down inside this and then I realized down here  I needed some value I had from some earlier point in the call chain and without having  to rewrite everything in between I was able to change that.  So this is an example of where a functional programming style and keyword args give you  code that's more flexible.  Anyway, that was just a little crazy thing I discovered that I'll put a post on my blog  about describing that in more detail.  Nearly out of time but in summary keyword args are clearer.  They are more functional in a couple of different senses.  They invite you to write a more functional, simpler style of code much of the time rather  than an object-oriented bureaucracy.  And they are more flexible.  Thank you.  Thank you.
Keyword_Args_0_47.png Keyword_Args_48_119.png Keyword_Args_120_167.png Keyword_Args_168_239.png Keyword_Args_240_395.png Keyword_Args_396_4127.png Keyword_Args_4128_5243.png Keyword_Args_5244_6275.png Keyword_Args_6276_8351.png Keyword_Args_8352_9011.png Keyword_Args_9012_10751.png Keyword_Args_10752_13223.png Keyword_Args_13224_16655.png Keyword_Args_16656_17759.png Keyword_Args_17760_21191.png Keyword_Args_21192_21263.png Keyword_Args_21264_21359.png Keyword_Args_21360_22427.png Keyword_Args_22428_25271.png Keyword_Args_25272_25991.png Keyword_Args_25992_26147.png Keyword_Args_26148_26182.png
All right, it's five past, so I'm going to get started. But before I go on to the content of the talk, I feel like there's something I have to address which is the election. This is very important. The District of Columbia has sent a petition or is about to send a petition to the Congress asking to be made a state. This will make the District of Columbia the 51st American state. But I think we're missing an opportunity here. I think what we need to do is pick two more places, Guam and somewhere. Puerto Rico, make them states because then we'll have 53 states which is a prime number and America will be a nation indivisible. Thank you. Thank you. My wife said I should open with a joke. That's the only joke you're getting, though. Who here is using keyword arguments in their Ruby code? Who here would say they're using keyword arguments enthusiastically in their Ruby code? Like in most places. With any luck, this will be the most useful presentation or one of that you see at this conference because if I do my job right here, you will leave here and change the way you write your Ruby code in a significant way. So I say the keyword arguments is a killer Ruby feature you're not really using. Who am I? I've been a software developer for 20 years. A Ruby developer for 10. I was in the room when Twitter was publicly announced for the first time in Austin, I believe. It was about when I started using it. I taught at a boot camp for a Ruby web serving framework. I've been told if I mentioned this Ruby web serving framework at this Ruby conference which isn't about the Ruby web serving framework, that Burley men will come in and drag me out. So I taught at a boot camp for that for about a year and I do consulting around that and postgres and I decided to start work because people don't use postgres and databases well enough in this community. I'm going to work on a book about that. Here's what we're going to talk about. We're going to make it clear what keyword arguments are and what they do, how they make your code clearer which might seem simple and obvious but there's a little more to say about that than you might think. And then I'm going to talk about how keyword arguments can make the functions that you're writing more flexible and more functional in a couple of different senses. So let's start with how keyword args work. Here's an example of a method declaration in Ruby that has every possible way or every kind of argument. So there's a positional required argument, a positional optional argument, positional argument splat, a required keyword argument, an optional keyword argument, a keyword arg splat which it turns out is super interesting and the block thing. Now the clever folks who've implemented this feature have done a great job of making it nice and intuitive. So you can call a keyword args function like that. You can take a hash and then call it like that. If you're using something from like a millennia ago in internet time, you can call it like that. This is a nice feature that I don't believe you can do with positional args. A keyword arg, an optional keyword arg can refer to an earlier keyword argument for its default value which is really nice. And you can splat hashes into other hashes. So that's all very nice and intuitive and simple and fairly easy to use. A couple of caveats, you have to put the positional args all before the keyword args and because it does this business of interpolating hashes into the keyword args, if your last positional arg is a hash, Ruby can get confused. Yes, we're getting nodding over here. So I think it seems obvious that the main thing that you're likely to get out of keyword args is that that is clearer. Here is a method that you might call from the Ruby standard library. And unless you've worked with this function very recently, I defy anybody to tell me what all these arguments are. They are in fact the server you want to hit and it's port. The proxy server you want to use, the port for the proxy server and the last two arguments are no, they're in fact the username and password for the proxy server. That's what's talking about how Ruby is a human-centered language and I'm afraid this is bad. We can do better now with keyword arguments. So let's imagine a different world in which the Ruby standard library was rewritten around keyword arguments and what this method call might look like. Now if you may have experimented with using keyword args and found yourself writing something like that and gone, it's sort of better but there's just ASCII salad up here, you can't tell at a glance what's a keyword and what's an argument. It's sort of maybe a bit better but not really. And fair enough. The problem I think is this book. Now let me be clear, I am an enormous admirer of this book. If you have to write any kind of technical book, you could do better than slavishly copy this book in every way you possibly can. Furthermore, I don't think we would be here today if it wasn't for this book. We, well, Matt's wouldn't be here at all and the rest of us would be at a Java conference or something awful. Not only did it, was it responsible for teaching us all to use Ruby and showing the world what an amazing language it is but it established a lot of the conventions that we all use which is one of the delights of using Ruby. You can go and read somebody else's code and because we all use the conventions that are established in this book about how we write identifiers and blocks and all the rest of it, it's established a really nice sort of set of conventions. However, this book was written something like 15 years ago and I don't think they have a version that covers the keyword args feature yet. And in any event, I think the conventions we've all got around formatting our code come from this version of this book. So in some ways, if we are to move on and use these new features, we have to be prepared to move past that book. So if you're going to use keyword arguments and there's more than like two of them, I think you should be prepared to write your Ruby code like this. People, many people have suggested this to have like kind of horrified but I think it's, it is quite clear. In fact, I can't imagine a way of making what you're saying here much clearer. All right. I defy anyone to tell me that the bottom one is better in any way. So I've been going around, since I started really digging into keyword args, I've been going around saying this to people and they're all like, yeah, okay, sure, it's, you know, it's a bit clearer. But I have to, to make it clear, I have to change the way I work and I like the way I work and if I hire new people or show my code to someone else, they're not really going to follow it. And you know, I kind of really like my buggy whip. And it's fair enough. Like that's not enough reason to go away from here and start changing everything about the way you write code, right? But there's one advantage you can have, which is that it's clearer. There is a clear advantage though to keyword args, which is that they are strictly more flexible than positional arguments. The first and most obvious way is that the optional arguments are all actually optional. So with positional optional arguments, you have to supply them left to right. I can't just give the third one. But with keyword arguments, I can pass in whichever ones I happen to need for the job at hand. Keyword argument functions are strictly more flexible. Let's look at an example of what that might look like. Let's say I'm using some sort of a Ruby web serving framework. And I'm calling a controller functions, calling a rendering function. And then later on, I decide, well, I've got a new controller now and it needs to be able to control what the headers look like. Well, I can add a headers argument to my function, now switching to the new style here in the function definition as well. And now I can pass that in. And later on, we decide, well, we'd like to be able to control the striping in the table, say. So now I can add a stripes argument and pass that in. Now notice that one controller is passing in one optional argument, the other controller is passing in a different optional argument. And it's all nice and clear and easy to follow. Versus, if you tried to do the moral equivalent of that with a positional argument function, you'd do something probably like that. And then you'd call it something like that. And that's obviously harder to follow, but pass two or three optional arguments, you're just not going to bother, right? You're going to switch to some sort of object-oriented solution, which is going to be more complicated. You're going to have an initializer and then state that you've got a track. This lets you do things sticking to functions in Ruby. And that's sort of where the industry is going, right? Somewhat away from object-oriented bureaucracies and more towards a functional style of programming. And much of my message here today is that keyword args invite you to use Ruby in a more functional sort of style. In fact, I see nothing wrong with having lots of parameters, lots of optional parameters. It'll be a bit long, maybe, but not hard to follow at all, I don't think. If this is a function that does a single thing and there's just a variety of different options for how it should do it, I think this is fine. Why not? So keyword args are more flexible and they allow you to rewrite code in one place without having to change all the users more easily than if you'd used positional arguments. There's a term for that, it's called loose coupling. And that ability to have all the sort of assumptions up the top and to change them as you're going, as you need, it's known as dependency injection, and both of these things are better if you write your functions using keyword arguments. In fact, let's imagine that we're back in like 2005 and you're working for a small company that's developing some sort of a Ruby web serving framework. But you have Ruby 2.3 available to you and they say, we need a quick and dirty solution for an ORM, right? I want something where I can just sort of throw a where clause and an order by clause and it'll generate SQL for me. If you had Ruby 2.3 available rather than the object oriented bureaucracy that you might have done, you could do write a function with a signature much like that and if you think about turning that into an SQL function, expression, it's cake, right? So there's a lot of the time when you would, until now, have written object oriented classes and all that, this feature invites you to adopt a more functional sort of style. So I mentioned the keyword argsplat as being super interesting. So let's start out with the simpler uses of it. Say you have a salary calculation function and then someone comes to you and says, we'd like to be able to override the arguments of that function on a per user basis. So there's a default set of behaviors and certain users get it different. So what you do is you add a JSON field to your user table and you just do that. So what's really nice is that you can treat a hash in Ruby now as a kind of canned partial function or whole function. There's a term in functional programming called curring and Ruby has a curring feature but you can actually treat hashes now as something along those same sort of lines. And if someone says to you, okay, well, I want, they'll be right on a company basis and then override that on a per user basis if I want, that's also cake. You just add a JSON field to company and you're done and it's functional. It's more functional in a couple of different senses, right? You're invited to do a functional solution and it's easier and quicker to do. So I hope that's enough to convince you that you might like to leave here and go home and maybe start writing your Ruby a somewhat different way and writing much of it or nearly all of it around keyword arguments because they're just better. Let me now illustrate something a little sort of wacky and crazy that I've discovered. I've not seen this, anybody else talk about this although I'm sure somebody else has discovered it but it's a fun sort of interesting thing to look at to end this talk. I call it the context funnel. So here's what it looks like when you use it and it just involves putting this star, C for context, splat at the end of your functions. In fact, what you do is in all the functions that you're writing and calling, not framework functions that you can't control, you always receive this splat and you always pass it on. So let's see what that lets you do. Let's say I'm using a Ruby web serving framework and I'm calling a render table function and maybe it looks like this. Now since this is the first function I've called from my code, I'm adding the star, C and in other functions that I call that I've written, I pass it on. Then maybe render row looks something like this. So the parts of my code that I've written in this case are view. I pass that C on to again and maybe my view starts out looking something like this. So I've got this sort of call chain that starts up at the controller with render table and ends with that view. Let's say now in some cases I want to be able to format that last name differently. So this is a sort of moral equivalent of the keyword args for a view, I think. So I'm allowing you to set a value if you want and if not, I'm giving it a default behavior which is do the same thing we did before, right? Now look what I can do. Back at the top of that call chain without changing anything in between, I can pass in this argument and it gets passed down by all the functions in between because they didn't understand it and they didn't care about it and it winds up down at the view. This is really interesting to work with particularly as you're sort of exploring developing code, I was doing something or I was parsing some complicated EDI code and I was writing all these functions and they were digging down inside this and then I realized down here I needed some value I had from some earlier point in the call chain and without having to rewrite everything in between I was able to change that. So this is an example of where a functional programming style and keyword args give you code that's more flexible. Anyway, that was just a little crazy thing I discovered that I'll put a post on my blog about describing that in more detail. Nearly out of time but in summary keyword args are clearer. They are more functional in a couple of different senses. They invite you to write a more functional, simpler style of code much of the time rather than an object-oriented bureaucracy. And they are more flexible. Thank you. Thank you.
talk about how keyword arguments can make the functions that you're writing more flexible and prepared to write your Ruby code like this. change all the users more easily than if you'd your Ruby a somewhat different way and writing able to change that. So this is an example of summary keyword args are clearer. They are more