 This is Ruby. Now if you think I've lost it, and this is clearly JavaScript, don't worry, we'll come back to the slide. This is Ruby. If you think I've lost it, don't worry, we'll get back to the slide because the title of this talk is Ruby is the best JavaScript. My name is Kevin Coocta, and I work at a mental health startup called Joyable. And at Joyable, I am a full stack developer, and what that means is that I write bugs in both Ruby and JavaScript. And what I would like to demonstrate over the course of this talk is that it's possible to do both at the same time. Now, before I get started on that though, I would be remiss if I were to give a talk on combining Ruby and JavaScript without describing at least a few good ways of doing that. So let's say you have a pile of Ruby, and for some reason you'd rather have a pile of JavaScript. Well, there's a tool that will do that for you called Opal. It will let you compile Ruby to JavaScript so you can then run it in a browser environment or a node environment or whatever. Conversely, if you have a pile of JavaScript, you want to run it inside of your Ruby. There are actually several tools for that, one of which is the gem, the Ruby Racer. It will let you embed JavaScript in Ruby, which is pretty cool. Now, of course, these are both pretty reasonable and mature approaches to combining Ruby and JavaScript. And as such, they stand in stark contrast to the monstrous affront to good taste that is the rest of this talk. And so in that vein, this slide is the inspiration for this talk. This is an image that was floating around on the internet a few years ago. And if you can't quite tell, this is Java code that has been bent out of all recognition to look like a whitespace-sensitive language. They've pushed all the semicolons and curly braces to the far right-hand side of the screen. Now, I don't actually know the story behind this image, but I like to imagine it was, I don't know, a Python programmer being forced against their will to write Java code. And they were not going to go quietly. They were going to write Python, even if they had to do it in Java. And so a lot of people on the internet saw this and thought, wow, what a terrible idea. I saw this and thought, wow, I'll bet you I can do worse. And I did. This unholy abomination is what I came up with. It does exactly what it looks like in both languages. It's both functional Ruby and functional JavaScript. It defines a couple of variables, defines an anonymous function, evaluates that function and prints out the result. This is, to my mind, a testament to the great and terrible things that Ruby lets us do. And so I would like to walk you through how this was accomplished. Both the cool metaprogramming techniques and the dumb syntax tricks that went into making it happen. So starting with the latter, let's take a look at how var was accomplished. As if you don't know, var is how you define variables in JavaScript. There are, of course, newer and shinier ways to do it in the latest versions of JavaScript, but we're gonna stick with classic JavaScript for this talk. So we can do that in Ruby with, by just defining a var method that takes one argument and does absolutely nothing with it. And this works because in Ruby, assignment is an expression. That is to say, it returns something. So first equals three, returns the thing on the right-hand side of the equal sign, three. And so three gets past a var, but the assignment still goes through and var just does nothing. And because this is Ruby, we can just drop the parentheses on a method call and heck, we can even slap a semicolon on the end to make it look even more JavaScript-y. And so with that, we've got variable declaration that works in Ruby, but looks like it's JavaScript. In fact, if you copied and pasted this last line into JavaScript, it would totally work. And so with that, we've taken our first tiny step in our awful, awful journey to make a Ruby look more like JavaScript. Continuing on, let's take a look at console.log. If you don't know, console.log is how you print a standard out in JavaScript. You'd use puts to do the same thing in Ruby. And just taking a look at this, you might already have some ideas as to how we go about it. We, I don't know, let's create a console class. We create an instance of this class, and this class has a method named log that takes an input and prints it out. Great. Let's do that. So we've got a console class, log method, takes an input, prints it out. And it works. We can create a new instance, console with a lower KC, because that's what it is in JavaScript, and now console.log with a string will print out whatever we give it. But there are two problems with this. The first is that we have this console class floating around that we don't really need. We really only need this console object with a lower KC. It would be cool if we could just have the object without creating a class first. Now our second problem is that our console.log only takes one argument. The real console.log in JavaScript takes as many arguments as we want. Well, that is pretty easily rectified. We can just use the splat operator. Now, don't ask me why we call it a splat operator. It's clearly an asterisk. But we're programmers, we have to be difficult, so we call it a splat operator. You stick it before a parameter and a method declaration, and now this method will take as many arguments as you want. Zero arguments, one argument, 100 arguments, it's all good. Here, I've got a function with a splat operator in it, and I can now pass in, let's say, three different strings. And now this function will take all those arguments, cram them into this one argument as an array. I can now do whatever I do with a normal array. You can grab the first element, the last element, I can iterate over it, map over it, reduce over it, whatever. And you could probably guess how we would use this to improve our log function. To find a log function that takes a variable number of arguments and joins them together, like we might join any array of strings and prints the result. So we call a log with, say, two strings, and it totally works. This will print out hey, comma, world. But all right, that's one problem to deal with. Let's deal with that other problem we had. We have an extra class floating around that we don't really need. So to deal with that, let's take a closer look at Ruby classes themselves. So here is your bog standard Ruby class definition. Use the class keyword, give it some name, in this case the constant foo, and then we create a new instance of it with foo.new. So bar is an instance of class foo. Bar has class foo. What's cool in Ruby is that everything's an object. All objects have classes. Classes are also objects. So bar has class foo, but foo also has a class, which is class. Heck, even the class class has a class, which is itself class, making this the classiest slider like this see in this whole conference. Now, this is useful for us because there's another way to create classes. We can just call class.new and give it some block. And what you put in this block is whatever you would normally put in a class definition to find a bunch of methods, for example. However, unlike the class keyword, class.new doesn't just create a class that's now floating around somewhere in the current scope. Instead, it returns a class object. And here I'm shoving it into a constant called foo, and now I can call foo.new to create a new instance just like I normally would. What's helpful for our purposes is that we don't actually need this intermediate foo variable. We can just call class.new, give it a block, and then immediately call .new on that. So bar is being set equal to an instance of a class that only exists inside these parentheses. And that's kind of what we wanted, right? An object without having a class floating around in the current scope. So we're kind of partial credit for this. We're kind of there. But we're still actually creating a class even if it only exists inside these parentheses. It would be handy if we could just directly create a new object in Ruby. And we can, with object.new. Object.new gives you a super bare bones object, an object that has no interesting methods whatsoever, except for the basic methods that are on all Ruby objects. So if we wanted to add anything interesting on this object, we'd have to add a method to it somehow. Well it turns out in Ruby it's totally cool to just add methods directly to objects. Just define them like you normally would. Def barred out whatever, we'll add a whatever method to the bar object. And now I can call barred out whatever from here on out and it will totally work. Now, this is kind of a handy technique if you need to create, for example, a dummy object somehow. For example, let's say you're writing some tests and for whatever reason you don't have a mock library on hand. Well you can use object.new to create a new lightweight object. And then directly define methods on it that just return hard coded values. And then you can pass this lightweight object to whatever method you're actually testing. All right, let's get back to our JavaScript nonsense. Here's what we have. We can use object.new to create a lightweight console object. We can call console.log with a variable number of arguments, join them together and print them out. And it works. Console.log now takes variable number of arguments just like the real console.log does and prints them out without having a whole extra class floating around in scope. And so because we are bad people, we've succeeded in making Ruby look just that much more like JavaScript. So we've dealt with var, we've dealt with console.log, but the heart and soul of JavaScript is really functions. So let's tackle that next. So here's your basic JavaScript function declaration. We're gonna try to create an anonymous function. That is to say a function that doesn't necessarily have a name. It just gets shoved into a variable and passed around like any other variable. You do this in JavaScript using the function keyword. Again, there are newer and shinier ways to do this with arrow functions in the latest JavaScript. We're gonna stick with classic JavaScript for this purpose. So you give the function keyword, you give it some parameters it's gonna take and some block and curly braces, great. And you call it by just doing the variable name with parentheses or argument parentheses. In this case, I'm defining a function that just takes two arguments, adds them together, returns the result, so we'll call it sum. It turns out Ruby can also do anonymous functions. In fact, because Ruby is three times as cool as JavaScript, there are three ways to do it. Box, crocs, and lambdas. And there are lots of interesting, intricate, and frankly subtle distinctions and differences between these methods, none of which are remotely relevant to this talk. So if you'll bear with me, I would like to stick our collective heads in the sand and pretend that only proc exists. So the way you create anonymous functions in Ruby is proc.new, and you give it a block and what proc.new returns is a proc object that does whatever that block does. So again, we're defining a sum function and you can call it by using sum.call and giving it some arguments or heck, there's even a shorthand using square brackets. And this does sort of the same thing that the JavaScript stuff does. Now what we want to do now is write some Ruby code that looks like the stuff at the top under JavaScript but actually does the stuff at the bottom under Ruby. And to do that, we're gonna have to start getting creative. So let's take a closer look at that JavaScript syntax itself. Here it is again, and if we sort of squint, tilt our head, cross our eyes, it already kind of looks like Ruby syntax, right? Like imagine if instead of being a keyword, function is just a function call. A function that just happens to be named function, a function function. And it's taking an A and B as arguments, whatever A and B are, and the stuff in curly braces is just a Ruby block. I mean that seems kind of valid at least, at least syntactically valid. Not valid in any other meaningful way. So I guess we would define that function something like this. We've got a function named function that takes in a variable number of arguments and a block. And since our function function should return an anonymous function, well we know that's a proc. So we'll return one of those. But there's a problem, and it's not just that we're attempting this monstrosity in the first place. The problem is what are A and B? In JavaScript land, that's how we tell the function we're creating what arguments it should take. In Ruby land, well, we're passing them into our function call, which means they need to be previously defined somewhere, and they're not, so this will throw an error. To get around that, we are gonna have to get really creative. And I should clarify in this talk, when I say creative, what I mean is do terrible things to code. So to that end, let's add a few more tricks to our Ruby toolbox. The first of which is main. It turns out in Ruby, if you're typing along outside of any context, you're not in a class, you're not a function, you're not in a loop, you're not in any interesting context at all, you're actually typing in the context of an object called main. And we could prove this to ourselves by this opening up IRB, the basic Ruby REPL, and type self. And normally if you were in an object, self would give you a reference to that object. Since we're not, it gives us a reference to main. Now we don't know anything about main yet, but we can inspect it a bit. We can call self.class and find out that it's an instance of the object class. So it's one of those bare bones objects we were looking at earlier. Now if we wanted to add any interesting functionality to main, we could try defining methods directly on it. But let's take a different tact. Let's try adding methods to main's class. And since main is just an instance of the object class, we can add methods directly to the object class. It turns out it's totally cool or at least allowed to add methods to classes that already exist. You can do this by just pretending they don't exist and redefining them. So here I'm reopening the object class, adding a foo method that just returned the string bar. Well now if I type foo, I'm actually typing main.foo and since main is an instance of the object class and the object class has a foo method, foo returns the string bar. Of course there's something I haven't mentioned yet about the object class which some of you may know and that's that it is the root class, a class from which all other classes in Ruby inherit. And actually someone's probably gonna come up with an exception that I don't know about. So let's just say most, nearly all classes inherit from the object class. Including for example, the integer class. So three.foo also returns the string bar. I have in fact added a foo method to every object in all my entire code base and all of the Ruby standard library and any object, any gems I might have loaded. I probably didn't actually mean to do that. If you do for some reason want to add a method to every object anywhere, this is a good way to go about it. It doesn't come up all that often in the real world. So a more practical technique is method missing which I think there's actually a talk about either today or yesterday. But method missing is a really cool technique. It's a blessed method. That is to say, if you define it on a class, then it will do magical things just by virtue of what you've named it. So define method missing on a class and for instances of that class, if you call a method that doesn't exist, method missing will get invoked instead. So here I've defined it on this foo class. I create a new instance bar. Let's say I want to call a non-existent method on bar. For example, bar.nonexistent. As the name suggests, this method does not exist. And so our method missing will get invoked instead. And method missing always gets, as its first argument, the name of the method you tried to call. In this case, non-existent. And since our method missing just returns the first argument it gets, bar.nonexistent returns the symbol non-existent. Method missing is super handy. So you can do a lot of things with it. One of the things you can do with it is as a sort of a way to effectively define methods at runtime. So say you've got some object you wanted to respond to a bunch of methods but you don't know what those methods will be until the code's actually running because that list of methods is coming from an API call or user input or the database or whatever. You can use method missing to handle those methods at runtime and have it not throw an error when you call a method you didn't manually define. But all right, that's a pretty reasonable use case. Let's go the opposite direction and think of the least reasonable use case we can possibly think of for method missing. For example, what if we were to define a global method missing method? It just returns the first argument it gets, the name of the method you tried to call. Well, if I type A, I'm actually typing main.a, main is an instance of the object class, object doesn't have a defined, so method missing gets invoked instead and it just returns the symbol A. B returns the symbol B, C returns the symbol C, whatever returns the symbol whatever. And of course, because everything inherits from the object class, three dot whatever also returns the symbol whatever. I have in fact made it so that any method I call on any object anywhere will either have been previously defined or will evaluate this method missing. I have in fact made it impossible to get a no method error, which is great, right? Fewer errors is always better, who wants more errors? This is an amazing idea, you should put it in any code base you have access to. Okay, so to be clear, this is a terrible idea, you should put it in no code bases you have access to. Because as I said, I made it impossible to get a no method error, even if I should. So like if I type of a method and I would expect a nice, useful error, instead my method will just keep working. It will return something completely incorrect, but it will work and so the best case is that I get a much more confusing error much later. The worst case is that I just get incorrect user input. So in fact, so I don't think there's any legitimate use case for this. And if you come up with one, please tell me because I could not think of one no matter how contrived. But it does make our function function work. Remember, we have a function named function, it takes an A and B which weren't previously defined. Well now we know, they will become the symbols A and B. So we don't know how function function works yet, but we know how we can call it without getting an error. I do need, before I move on though, I do need to add a caveat. This technique is such a bad idea, it doesn't actually work as described. It turns out there are certain bits of the Ruby standard library that rely on being able to call methods that don't exist and get an error. And if they don't, it explodes. These methods I determined are to A, to hash, to IO, to string, to array, and to int. There may be more, I determined this list experimentally using the tried and true debugging technique of changing my code until things stopped breaking, which just goes to show you what a robust technique this is. So, back to our JavaScript nonsense, here's what we have so far. We've got a function named function, it takes in A and B, which are actually the symbols A and B, and some Ruby block. But Ruby blocks take their arguments using the pipe syntax. Pipe A comma B pipe. But that's not a JavaScript thing. So we're gonna have to figure out how to get rid of that. To do that, we're gonna have to get, once again, more creative. So continuing our headlong march into privacy, let's take a look at some more metaprogramming with send. Just probably the simplest bit of metaprogramming you'll ever see, send calls a method. So I've got some object, in this case just an array, I can call some object dot first. That is how you call a method, hopefully people know that. But I can do something similar with some object dot send and pass it the string first. This will also call the first method on some object. Now, something to note is that send will bypass, it will totally let you access private methods. So in the real world, you probably wanna use public underscore send, which will do the same thing, but will respect private methods. But because I'm limited in the length of lines I can have on slides and still have you read them, we're gonna stick with send because it is shorter. All right, next technique is less a technique and more just something that is useful to know. That is that in Ruby, attribute assignment is a method call. So what I mean by that is, I've got an object here, it has an attribute foo, I can give foo a value with object dot foo equals three. What I'm actually doing here is, I'm calling a method named foo equals on object and passing it three as an argument. And this might seem like a minor syntactic quibble and it is, but it's useful for our purposes because there's another way to do the same thing. We can call object dot send, give it the string foo equals and pass it three as an argument and this will do the same thing. This will assign three to foo. All right, last technique for the moment is instance eval, which I think is especially nifty. Instance eval will evaluate a block of Ruby code in the context of some object. So I've got an object here, it has attributes a and b, I can give it some values, object dot a equals three, object dot b equals four. If I wanted to add a and b, I'd have to do object dot a plus object dot b. Or I can do object dot instance eval and give it the block a plus b. And this will work, this will return seven because this block will be evaluated as though we're running in, let's say a method inside of object where a and b are in scope so I don't have to prefix them with anything. Also note, I didn't have to add any arguments to this block, which is how we're gonna make our function function work. So now we have the pieces that we need to make that function function work. Here it is again, we've got a function named function that takes in some number of arguments and a block. And in our example, that's a and b, b which are actually the symbols a and b, which because we're using a splat operator becomes an array of the symbols a and b. And our block, since we're just defining a sum function is a plus b. And what we want our function function to return is an anonymous function in Ruby, a proc. Our proc will take in some arg values, the values for our arguments. In our example, that's three plus four, no, three and four rather. Okay, so now let's do a little bit of setup. We're going to create a class with attributes drawn from our args. So this class has the attributes a and b. Now we'll create a new object that is an instance of that class. And now we want to shove our arg values, three and four, into our arguments a and b on object. So we can do this manually by object at a equals three, object at b equals four. But we need to do this in a generic way because we don't know how many arguments we're gonna get and how many arg values we're gonna get. So let's do that with some mumbo jumbo using zip, each and send. Don't worry about parsing, that's too much. Just know that we're doing the exact same thing we just did, object at a equals three, object at b equals four in a generic way. So now object at a and b are defined. We can just evaluate our block a plus b in the context of this object that has a and b defined with instance evo. And this will work. This is what we get. We've got a function function that takes an a and b, which are actually the symbols a and b and a block. And what it returns is a proc that does whatever that block did. We can try this. We can call sum.call, give it couple of arguments and it returns seven, it totally works. So we're halfway there. We've got JavaScript style function declaration and JavaScript style, but not JavaScript style function invocation. We have to do this dot call nonsense, which is how you evaluate procs. We need to find a way to get rid of this dot call syntax. So to that end, we are going to have to get even hackier. Let's add one more technique real quick. Define method does just what it says on the tin. It defines a method. It takes a string and a block and defines a method in the current scope named to that string that does whatever that block did. So here I'm using it to rapidly define four methods. Get one, get two, get three, get four. And it works. Food.get1 returns one, food.get2 returns two. Notice I didn't have to type def get one, return one, end. Def get two, return two, end. Def get three, et cetera, et cetera. There are a lot of good use cases for define method. One of them is as a rapid way to define a lot of very similar methods without having to do 12 lines of method declarations. I can just do it in three. But all right, back to our JavaScript. Remember, our function function just returns a proc. So we're going to shove that into a temporary variable, just call it funk1234 for the moment. And then we're gonna call define method. And at this point I would like to continue our proud tradition of completely ignoring the differences between blocks, procs, and lambdas. I'm using the ampersand symbol here to magically convert a proc to a block. Just roll with me on it. All our define method is doing here is defining a method named sum that does whatever our funk1234 method did. And at the end you can see it works. There's now a method in the current scope named sum that takes two arguments and adds them together and returns the result. This is what we wanted, right? A function that we can evaluate like we would in JavaScript. We just need to get rid of this cruft in the middle, this temporary variable, and this define method call. So we're gonna hide some of this logic in our function function, and some of it in our var function, which did nothing at the beginning. So to do that, let's reach a little bit deeper into our grab bag of Ruby Meta programming tricks, starting with local variables. Local variables is another rather self descriptive one and gives you a list of the variables in the current scope. So if a equals one, b equals two, local variables gives you a list of the symbols a and b. Now, importantly for us, it only gives us the names of the variables, not the values. So that'll come up in a few minutes. Next up is eval. If you come from a language besides Ruby, there's a good chance you encountered something similar because a lot of languages have a very similar construct. Eval takes a string and evaluates it as though it were Ruby code. So here I'm evaling three plus four and if three plus four were Ruby code, it would return seven. So evaling it gives us seven. Eval also has access to the current scope. So if you eval a string that references x, it will work. Now, the primary use case of eval in the real world is introducing new and exciting security holes. So let's say I'm writing hello world, but not the v1, the v2, where you are taking some user input like a user's name, like Kevin, and you're gonna print out hello Kevin. I can implement this somewhat naively with this. Eval, eval with a string that prints hello and then some user input. And if input is, let's say, Ted, this will work, this will print out a very polite hello Ted. Now, if my user is slowly malicious and even a little bit clever, they could decide instead of Ted, their name is actually this string. This will very politely print out hello Ted and also incidentally delete all of my users. So don't do that. If you're going to use eval, be extremely certain that no user input ever gets interpolated into it, into the string that you are evaling. If they do, if that does happen, then users can execute arbitrary code in your environment. So that's generally frowned upon. But all right, back to our function function. Here it is again, somewhat abbreviated. Remember, the main thing we did before was create a new proc. Previously, we just returned it. Instead, I'm going to pick a new function name. Let's give it a random name, funk underscore and some long number. And for the sake of discussion, let's say that turns out to be funk underscore one, two, three, four. So our funk name is funk one, two, three, four. We're going to define a method named funk one, two, three, four that does whatever our function block did. And finally, we're going to return our funk name, which is funk one, two, three, four, resulting in some of the funkiest code I've ever written. Now, to recap, we're creating a proc, defining a method that does whatever that proc did and then returning the name of that method. So now let's take a look at our var declaration. Here's the original version, a method that takes one argument and does nothing. The way we've been using it is var sum equals function yada yada yada. And as we know, this is actually sum equals function yada yada yada and then passing the result of that assignment to var. And since our function function just returns the string funk one, two, three, four, we're actually doing var sum equals function one, two, three, four. We know at this point there's a method floating around in the current scope named funk one, two, three, four that does what we want. What we'd rather have is a method floating around in the current scope named sum that does what we want. So var is going to sort this out. But so far it's going to create a sum function, but how could it possibly do that? Var doesn't know anything about sum. Remember, assignment is an expression and it returns the thing on the right-hand side of the equal sign, which is the string funk one, two, three, four. Var doesn't know anything about sum. So how could var possibly create a method named sum? Well, I'll show you. Let's take a look at our var declaration again. I've switched from using def var to define method var for scope reasons that aren't super exciting, so don't worry about it. Just know I'm doing the same thing, finding a method named var that takes one argument. In this case, we are going to do something with it. Now, we know at this point, two important pieces of information. We know that there is a method floating around named funk one, two, three, four. We also know there's a variable floating around in the current scope named sum whose value is the string funk one, two, three, four. So, okay, I need to pause for a moment here and be clear. This is the point in the talk where we abandon any and all pretense of being good and honest people because we are going to just search all the local variables in the current scope to find the one whose value is the string funk one, two, three, four. But of course, local variables only gives us the names of all these variables. We need the values. Well, given the name of a variable as a string, we have a way to get its value. Just eval it. If you eval a string x, it will give you the value of x assuming x is a variable in the current scope. So we're gonna iterate over every variable in the current scope evaling every freaking one until we find the one whose value is the string funk one, two, three, four. Exempting, of course, the one variable we already know has that value random function name. And so at the end of this works, our name should be the string sum. And now all we have to do is define a method in the current scope named a sum. It takes a variable number of arguments and calls the random function name funk one, two, three, four. So now we have a method named sum that does whatever the funk one, two, three, four method did. And it works amazingly enough. We've got JavaScript style function declaration and JavaScript style function invoke case. We have all the pieces we need with none of the cruft in the middle. So let's review how we got there. Let us review our crimes. And don't worry if you can't read this mess. In fact, I would be surprised if you could because I can't. But what's happening here is our function function defines a local method whose name is a random string. It then returns that random string which gets assigned the sum and also pass the var. Our var function has now been upgraded to search for local name space for a variable whose value is that random string. When it finds it, it finds a new method with the same name as that variable that just executes a method whose name is the value of that variable. That is to say the original method created by our function function. Now, if any of that was hard to follow, then good. I hope I've convinced you that Ruby meta programming is very cool and makes it extremely easy to write super confusing code. I can't keep that explanation in my head for more than about 30 minutes of the stretch which is why I had to read it directly off the speaker notes just now. So imagine if you wrote this code and then, I don't know, two years later you had to come back to it and figure out how the heck it works. That would suck. I know because I wrote this code and then two years later had to go back and figure out how the heck it worked to write this talk and it sucked. I had no idea how any of it worked. I had to figure it all out from first principles. So I tried to avoid that. In fact, take it one step further. Imagine that your coworkers wrote this code and then two years later you had to go back and figure out what the heck they were thinking. I would not wish that on my worst enemies. And I don't know about you but I actually think my coworkers are pretty cool. So I try to avoid inflicting this kind of nonsense on them in the real world. Thankfully, this is not the real world. This is a conference talk. So here's what we've done. Days upon our works, the mighty end despair. We started out by using Dilwap methods to make our bar declarations work. Then we used object.new to create a lightweight console.log method. Then we went completely off the deep end and used a global method missing technique and a local scope variable searching technique to make our function function work. This is functional Ruby and functional JavaScript. The fact that this is even possible is a testament to the power of Ruby's meta-programming, the flexibility of its syntax and the lengths to which I'm willing to take a bad idea just to see if it can be done. This is Ruby. If you have any questions or comments or just wanna come up and shake your head at me disapprovingly, feel free to do so after the talk. My name is Kevin Coocta and I apologize for all of this. Thank you. Thank you.