How about that: “Facets” of ruby. I’m so witty, it hurts. I’ll quickly go over methods and a sentence or two on expressions. Parallel assignments get a few more words, since it’s new. A bit on boolean logic, and case statements, because they’re cool. Finishing up with loops and a few words on scoping.
The book discusses defining and calling methods. This is a very fascinating topic, not. They only new thing there for me was “splat” args. The concept of rolling up all the arguments into one array and then you can hand that on to the super, or another method. The *args will get automatically expanded into parameters for the other method.
More things are expressions in ruby than in other languages. If statements aren’t statements, they’re expressions. If returns a value.
Parallel assignment is another new concept. Wierd, but useful. It makes it easy to swap variables. You don’t have to define a swap variable to switch things out. Nested parallel assignment travels down the dark rabbit hole of insanity. It’s ugly to look at, and difficult to comprehend. You can use splats to eat variables. You can have a single splat anywhere in the assignment (a, *b, c) and it’ll eat everything as long as the rest of the variables are satisifed. So you could eat everything in the middle, and just have the first and last ones assigned. I’m not really sure where this will be useful, but it’s there. Finally, there’s no ++ or — operator in ruby! You have to use += 1.
Theres the standard gamut of boolean operators, adding a few. && and “and” do short-circuit logic, so that’s nice. However, ”and” has a lower precedence than &&. To mix it up even more, “and” and “or” have the same precedence but && has a higher precedence than ||. I believe that could cause some really wierd problems for people expecting a certain behavior. I think I’ll stick to just using && and ||. There’s a construct for setting a value to a variable if it doesn’t exist: var ||= “default value”. Makes it easier than using an if statement. Flip-flops were mentioned again using conditionals and ranges. Perhaps if someone requests it, I’ll try to explain it better, but I think I understand the concept well enough and don’t really need to go into it again.
Case statements are far more powerful in ruby. You don’t have to have a simple type. Since everything is an object, case uses the method ===. That makes it really awesome. You can have a case statement doing regular expression evaluations to parse lines. Quite handy. You can attach a conditional to a statement to only run that statement if $foo evaluates to true. Reads nice and clean, however you can quickly descend into madness if you’re not careful. You can have if expressions that return a value only if $foo. So yeah.
y = if even then
6
else
5
end if assign_y == true
According to the text, ruby has lame built-in looping constructs, because iterators handle the majority of looping! You’ve got the standard while and until construct. You can attach while and until to a block, but the block will always be run at least once, regardless of the evaluation of the while or until. That’s not quite normal, especially since it won’t run a statement once. There’s “next”, “break”, and “redo” modifiers to manipulate flow of the loop. Redo is quite handy, makes it simpler than using recursion to reprocess a line. For .. in constructs are neat, basically it’s a cleaner way to write iterator |paramter| block code. It has a bit of scoping difference, so I’ll probably try to stick to the more explicit syntax.
A bit on scoping. Ruby 1.9 has a concept of block local variables, so you can define a variable that is scope limited to a block. The example in the book shows it pretty well, you have a variable called square, defined outside the block. You then use a variable square within a block, with a different purpose. Now my variable outside the block is broken, because the scope leaked. You can prevent this in ruby 1.9 by |; square| as a block parameter. It’s now local to that scope and your external variable is unaffected. Yeah, you could just use a different name, but this improves readability. At least, I think it does, my brain can handle keeping scope. Turning on ruby warnings (which by the way is appearing to be a good thing to do) will help you catch these scope issues.
