 I'm gonna talk about the new features of Ruby 2.0, the next major version of Ruby. So, this talk will be a pure Ruby talk. I mean, not a Rails talk. Sorry for the bit misleading title. All right. My name is Akira Matsuda. Matsuda on GitHub, probably known as a author of Caminari, and A, under Matsuda on Twitter, became a member of the CRB core team since when we got in New Orleans during the RubyConf last year. And I'm the founder of, I believe, the most active Japanese Ruby user group in Japan named Asakusa.rb. So, let's begin. As I'll tell you, I'm gonna talk about Ruby 2.0. Ruby 2.0 is planned to be released on the next February. Well, it's just three or four months since today. And Mats once stated that Ruby 2.0 will be 100% compatible with current stable version of Ruby. Well, who can believe it? At least, to be honest, I don't. But anyway, whether or not you believe or not, the next Ruby is said to be 100 compatible with the current stable version of Ruby, which means any of the existing application should still work, just work with Ruby 2.0 without making any change. And not only that, Ruby 2.0 has absolutely awesome new features, a lot of new features on which I'm gonna focus on today. So that means in total, it's a 200% Ruby. You know, that's why we call it Ruby 2.0.0. So, the new features. We just had the feature freeze event last week. So, what I'm talking today will basically be included in the 2.0 stable. So, I'm gonna talk about these four big features, particularly, refinements, module prepends, innumerable lazy, and keyword arguments. I'm gonna describe, I'm not gonna describe their internals deeply, but instead, I'm gonna tell you about some stories behind each of these features, and I'm gonna show you some useful real-word sample codes. Sorry. Ask the internals, don't ask me. Ask Koichi. Where's Koichi? So the first one, refinements. The feature called refinements was created by Shugo Maeda. I guess many of you still remember that he talked about his plan of this feature at RubyConf. It was 2010, I think. The author of Shugo is Matt's boss at the company named NACL. That means he is one of the highest majesty in the Ruby community. And he's also a chairman of Ruby Association, Ruby ORWJP, which runs Ruby Grand Program and host a conference named the Ruby World Conference, which will be held in the Ruby city, Matsue, in next week in Japan. And he recently joined user group, ahoxa.rb. So refinements. Refinements are, in short, a clever way of monkey-patching. As a background, there is a problem that monkey-patching by traditional class opening is considered to be sometimes dangerous or even harmful because it affects all instances in the Ruby process. For example, while there's an instance of person named Matt and then adding a new attribute onto the person class for another person named Shugo, the new attribute will also be added to the former Matt object. Do you know what I mean? So refinements are invented to improve this situation and provide a better way of monkey-patching. The feature called refinements are consistent with these two new methods, module-refine and kernel-reusing. So let's see how to use them. Module-refine. This is probably the simplest way of using module-refine. You see, here in a module named full, adding a new method to string class and calling it underneath. So what's the difference between good old monkey-patching and this technology? The difference is that you cannot call the method outside of this full module, right? In other words, the effect of this def-say thing here is confined to only the scope of this full module. Then the next method, using, having the same refinement module full, now you can set the ability of the module onto any other module or class using, using Q-Rid. In this example, here's another class named bar that declares using full, like this. And then the same method added by full can be called inside the bar class as well. The using method can also be used in a module like this. This time the bar is not a class but a module. And you can invoke the method, say, by a module eval. Now the module can, of course, be an anonymous module. So this way you can locally use the method, the same method without affecting the outside world class, I'm sorry, world string. So if you're familiar with JavaScript or other kind of functional programming language, you might think that you can use the lambda or proc for limiting the scope, the lexical scope. But unfortunately, that's not true. In this example, once you use the full module in the lambda, it affects all the string outside of the lambda scope. Actually, the world string now has the same method because you always need a block in order to limit the scope of using. If you really need the proc using refinements, you can do it this way. So that's the brief description of the refinements feature. Can you also, did you get it? So I guess you're now probably wondering how it can be used in real world applications. So I just prepared several sample applications, sample libraries in my GitHub repository. The first one is called RSpec refinements. The story behind this library is this syntax. I do prefer this should syntax over the expect and block syntax. In my opinion, this should think syntax is the taste of RSpec, I believe. But the reason the should syntax is going to be deprecated nowadays is that the should method is directly defined on the core basic class, basic object class, I'm sorry. Hence, just requiring RSpec actually changes the test target's application, which basically never happened, right? So, but I just want to use the should method only in the specs, but I don't want to change the whole application behavior. So let's see if I can solve this problem using refinements. The RSpec refinements is the name of the project. The code is available on GitHub and you can also jam install. The code is like this. Can you see it? What the jam does is simply undefined the should and should not at first and redefines these methods using refinements. Then injects the refinement module into RSpec example group in the before hook. That's all. It's super simple. And this is how it works. You see, the normal should method just works as usual, but the should method is not available outside of the example group. So just bundling this jam onto your project will make your RSpec a bit cleaner, I think. Next. Okay, the next project is the one called Active Record Refinements. The Active Record Refinements is doing something similar to your name in the squeal library. It lets you rewrite this ugly Active Record Query as this. What it does is it extends Active Record Refinements method to take a block and inside the block you can use some operates there on symbol instance, such as not or greater than or like, et cetera, et cetera. And in this jam, the column names are symbol and like squeal. And the code is unbelievably simple thanks to refinements. So here's the code again. You can also jam install. So let's take a look at the code. Firstly, there's a module that refines the symbol class to be able to respond to these operator methods. Oh, by the way, that percent I literal here is also Ruby 2.0 in a new feature that composes an array of symbols. What, an end? That's not an official feature. But you see what it means. And then creating another module defining the where method to which if not block given, then just call super at the very bottom. Else evils the given block and using a refinement module in the previous slide. Using this. Then convert the result of this array object into the arrow node. That's it. So then finally, prepending this module into active record query methods module in the active record query. As for the prepend method here, I'm gonna just describe about it later. So this prepend exact is actually somewhat related to the super call at the bottom here. Yes, and that's it. That's all. As a result, the small libraries enables this. You see that these symbols respond to the not equal or greater than equal operators and then generate the sequel strings. That happens only in the where block as you see the last example. You see it's a really elegant way of implementing your own internal DSL. All right, the next refinement example, active support refinements as a background story. I think there are two types of, two different types of libraries in active support. One is core X and the rest. What I mean by the rest are, for example, active support, loaded hash, active support JSON, active support, time with the zone, things like that. These are basically just providing their own class libraries. So if you don't like them, you just can ignore them. But on the other hand, the core X libraries are actually harmful or evil just by being there. Because when they are doing, what they're doing is shamelessly overwriting the Ruby core libraries or standard libraries like this. So only just by requiring the core X, this happens. And when once loads it, you cannot go back to the pure core library. So, by the way, along with Ruby, sorry Rails 3.0 release, Jeremy Kempu did a fantastic refactoring on active support so that we can selectively require the individual core X modules, for example. In this code, the first one, two, three, four, it has active support try method. But on the other hand, it doesn't respond to today's method because requiring the active support core X object try method by name. This way, you can choose only what you really need and reduce the global pollution by active support. However, this approach is still not perfect because, as I said, once you loaded the monkey patch, there's no way of loading it. So in this case, you cannot unload the try method. Particularly, if you're writing server-side Ruby applications, this would be very dangerous. For example, imagine you have a Rails controller like this. It looks like the required numeric time at the first line enables the three days ago in the middle. So before and after someone touches this controller, the behavior of numeric class changes. Imagine how it's dangerous. Actually, Rails framework requires active support all by default. So this code wouldn't be so dangerous indeed in your normal Rails application. But this case is just an example. So how can we more effectively and safely load active support monkey patches? It should be wonderful if you can arbitrarily load particular active support modules only inside certain limited lexical scope. Yes, time for appointments. So this gem does the magic, active support environments. See GitHub for the code and gem is also available. This example code by using active support refinements at the first line. Object try is enabled only on the first module. You see, this way you can avoid disastrous global pollution. You know what I mean? I said you can stop the global pollution. That means you can save the environment. You can save this planet. Awesome. So by using this feature, the format dangerous controller can be written like this. Now three days ago here just works, but it does not work inside of this controller. So that's it. Please know that this active support requirement library is really experimental and not all the modules are working at this moment. Sorry, why is it dangerous? Okay, because by default the numeric objects did not respond to, in this case, days. But once someone sends a request to this controller and the Rails process loads this controller, then the behavior of the numeric class changes before and after that request. That will cause some unexpected error. So, oh, by the way, I forgot to tell you one more important thing, refinements are experimental. And it could be reverted suddenly. I'm serious. Hope not. All right. So now it's finished. Then let's move on to the next feature. And I think I spent half of my presentation on time. Module prepent. The story behind this is in early Davis Rails, we had alias method chain, which was initially created by James Buck. Considered as a class named A having a method full. And you wanna add some new features onto the existing full method for this purpose. You can use alias method chains like this. The difference between the alias method chain and normal method overriding is that, none at all. Is it? You don't need to copy and paste the whole method of the original full method. Makes sense? So, as a real world example, here's a very simple code that extends active record three is page method, I'm sorry, relation class. Relation all method to take a page option to return the paginated query results. You see, the logic here is very simple piece of code. But to tell you the truth, this is actually like 90% of common origin does. So, alias method chain is certainly useful, but on the other hand, it has some kind of known problems. Now, consider there's a class having two alias method chains in one class, I'm sorry, in one single full method. Then, let's call one of the without methods named full without bar. The full is extended by bar and baz and I'm calling a full without bar method. Can everyone tell what's gonna happen? The answer is that full without bar method skips not only bar, but also it skips bar and baz. Who can expect this? The method named full without bar lies. It should be like full without bar and baz, right? So, the actual example of this problem is like this. On a bit, a little bit of active record. Actually, it uses the older version of active record, heavily used alias method chain. So, calling a method named save without dirty. Actually, it skips not only dirty, but dirty and validation. So, calling save without dirty immediately saves an invalid record into the dv. This is so dangerous and consider if you're installed more than two monkey patching plugins that alias method chaining onto one same method, the same thing should happen. It's possible and these two monkey patching plugins should invoking the without method internally. So, nobody can tell what's gonna happen. So, this is the problem. So, since rail three, the rail scored code gradually abandoning alias method chain and switching to more like modular architecture. For example, this commit by Yehuda totally eliminated the use of alias method change for active record. We've done in two years ago. For example, like this. It's just replacing the use of alias method chain into method override and super call. So, the format full bar base example can be written like this in this way. Using separate modules for bar and base and call super in each modules, then include each of these modules into the target a quest. There's a rule though or a restriction. The original full method has to call super. In other words, you can only extend methods that originally called super. But in many cases, what we'd like to do is to extend a method that does not call super inside. Right? So, how can we monkey patch this method without using alias method chain? I said, as I was playing, it has some risks. So, for this purpose, now we have module prepend in Ruby 2.0. This feature was proposed by Yehuda Cuts and implemented by Nobu. Nobu. This is Nobu. He's there. And we call him the patch monster because he's the monster. This is the whole Git log on Ruby, Ruby repository that shows Nobu is the definitely number one Ruby committer far above maths, right? This is why we call him the patch monster. In short, patchmong. So, in my opinion, in my opinion, Ruby is the language that maths designs and Koichi implements and Nobu fixes. And note that all of these three guys are now hired by Heroku as full-time Ruby committer. So, I really would like to say thank you to Heroku for sponsoring Ruby development in such efficient way. Heroku definitely pushes the Ruby development forward. It's so impressive that he's always drinking something, like beer in this picture, or sake or shochu or something. Even he's writing his Ruby patch. That is Nobu. Oh, and of course, Nobu is also a member of Asakusa RB. So, going back to the code. The alias method chain in this code can be rewritten like this using module prepend. You need another module defining the same full method and just prepend the method onto the class A, right? Of course, you can prepend multiple modules, in this case, bar and des, into the target class. As Matt explained in his keynote, what prepends us is like, it's something similar to include, but the order of method invoking is just reversed. So, this is module prepend version of the format simple pagination. I think the logic is not totally the same. For some reason, but anyway, it's kind of working the same. Just define, just create a module defining all method, then prepend it onto the active record finding methods module. It's so simple. And as I already showed you, there's another example of using module prepend in the format active record refinements gem. So, remember, there's a module defining where method and calling super inside and prepending that module onto active record query methods module. You see, it's far more readable, easier to read than at least method chain because there's no something with something method or things like that. Okay, it's done. So, the next feature, innumerable lazy. This feature was proposed by Yutaka Hara. He lives in a Ruby city Matsue, where Matt lives. And he's also working for NACL, the company where Matt and Shugo is working. As for the background of this feature and details of this feature, please just see the ticket here on red mine. Basically, what it does is, while each call on an innumerable object returns an enumerator instance, a new method on innumerable, innumerable named lazy, returns an object of innumerator lazy class. And what it can do with this innumerator lazy object is, for example, like this. Every enumeration method such as map or select, zip, grep, flat map. On this object will be deferred until you call 2A or force. Force is just an A list of 2A, I think. So, this way you can create an infinite collection like this. If you're not using lazy, this will never finish. But using lazy, you can defer the invocation of select even and take only 20 numbers. Or like this, you see it? It's basically the same. It's a script that picks up Friday the 15th. So, here's another really elegant example of using innumerable lazy by Y-Harris boss, Shugomaita. And actually, besides this sort of script, I'd be thinking of a usage of innumerable lazy in Rails application because I titled Ruby 2.0 in Rails, but unfortunately, I couldn't find any good example on Rails so far. So, I'm sorry, there's no gem for this feature. And maybe I can use it as a backend of active record for the interface, I think. Or maybe, for example, I can use on action pack live controller, I'm not sure. Or sprockets related something, I'm not sure. So, anyway, I could not come up with any good example. I'm sorry. So, please tell me if you find any. Anyway, in this example, Shugomaita is implementing a Ruby version of Unix root count command. Using two innumerable lazies. One is that it writes over it file names and one that lazily differs the files each lines, then counts the boorish. He says it's faster and consumes less memory. Consumes less memory. So, the next feature is keyword arguments. The keyword argument implementation was done by Yusuke Enzo. He's really an amazing super geeky hacker. He's a coin artist. And he's the release manager of the next release Ruby 2.0. So, actually, he controls the management, the release of Ruby 2.0. So, the background. This is a well-known and widely used idiom for imitating keyword argument-ish thing. Just use a hash object like this in the method argument. And in combination with Ruby 1.9 style hash syntax, it perfectly looks as if there's a language, native language support on keyword arguments. It really looks like Objective C or C sharp or something. But we need some tweak in order to use this method in our real applications like this. One is tweaking the default values. For example, if the full method takes the default values, A defaults to one, B defaults to two, we do something like this, right? We need to merge a default values hash into the argument. Or active support has a special command, I mean special method named reverse merge, which some kind of, kind of, not at all, looks better. I mean, kind of readable, but it's doing basically the same thing. So, the next problem is multiple hashes. There are tons of methods inside Rails that takes two or more hash arguments. So, there's actually a method named button two, takes two hash arguments. One is option and the other is HTML options. And if you would like to, if you wanna pass in any, what's that option into the last letter, HTML options, you need to write the hash literal onto the first action new parameter. Otherwise, the whole arguments will put into the first hash. So, this kind of looks ugly. Handling's splat operated. When the method having splat operator that takes variable arguments, and yes, this often happens, like, and takes the very last arguments of the splat option as a hash. So, this does, this extract option also defines an exit support like this. It just, if the given arguments last is a hash, then treat it as a hash. And last week, assert valid keys in order not to accept a valid argument keys, there's a method called assert valid keys in exit support. This is the implementation of assert valid keys. So, simple. And this is how it works, right? So, we need these kind of a lot of tweaks or workarounds in order to treat the hash arguments. So, there will be two point keyword arguments. I'll have one more minute, sorry. So, it treats default values, it does. And it can also treat multiple hash arguments splat operator like this. And it includes assert valid keys by default. Right? So, we need none of them. We need none of these workarounds. Yeah. The Ruby 2.0 keyword argument just does it. So, the conclusion. Everyone can upgrade a Ruby version immediately. Or, I mean, if you're brave enough, you could do so immediately. I mean, the SVN front version is also aimed to be totally compatible with Ruby 1.0.3. So, if any of the existing application except for C extensions does not work on Ruby trunk, that is a Ruby's bug. So, if that happens to you, you're so lucky that you hit a chance to contribute to Ruby 2.0. Then please file a ticket onto RedMind if you're concerned any such a problem. Or else, if you're not, if you're still not using 1.0.3, now's the time to move. Because Ruby 1.8 support will be dead very soon. You should abandon your Ruby 1.8 application as soon as possible. And standby for the coming Ruby 2.0. So, we encourage you to use Ruby 2.0 and use these new features because it's useful and fun. You know, if everyone uses these new features, then it will probably speed up the transition to Ruby 2.0. So, let's use 2.0 and let's deprecate 1.9.3 as soon as possible. That's all, thank you. Thank you.