Likin' RDoc

I've moved onto part 2 of Pickaxe. Currently on the RDoc chapter. I must say I'm impressed how smiple it seems to keep things. No fancy @param annotations to learn, just put a comment above your class / attribute / method and you're off. If you feel the need for more control of your formatting, you can get busy with a very wiki-like syntax.

Its also interesting to note that if you click on a method, RDoc will show you the code. It highlights a key difference between the Java and Ruby worlds.

Unit Testing in Ruby

Ruby comes with a Unit Test framework pre installed: Nathaniel Talbott's Test::Unit. The Pickaxe book devotes a whole chapter to it (and not at the back). These are good things.

Ruby I/O - Calling File.open with a block does the .close for me

More Ruby niceness. This should look familiar to all Java guys and gals out there:


Repeat after me: "Always be closing. Always be closing. Always be closing."

But Ruby's File.open can also take a block to associate with the call:


This invokes the block, passes the newly opened file to it as a parameter. When this is complete, the file is automatically closed for you.

In addition to this, if an exception ocurs in the first example then the close will never be called until its GC'd. (Bet you'd miss checked exceptions then). With the second example, the file is closed and then the exception is propogated to the caller.

Lost a Safety Net

I've just finished working through Chapter 9 of Pickaxe - Modules - and to be honest, it sacred me a little. Now I'm not religiously tied to static languages and can see the benefits something dynamic like Ruby can bring to me but there was something about Modules and name spaces which had me yearning for good 'ole Duke.

Here's the scoop. Mixins (using Modules as a way to provide multiple inheritance) allow you to provide instance variables. If I create an @myString instance variable in my mixin, and then in my class which includes it I also have an instance variable with the same name it can all go horribly wrong.

But here's the pain. In nice statically checked land, the compiler (best chum o' mine) will flag my goof. In Ruby-land, there is no compiler. Things might even work for a while. Worse still they miht break without my knowing it. Then finding the problem would be pretty nasty and debug-steppy.

Now I know I should have created a nice set of unit tests to avoid this, but in a complex application I can see things like this falling between the cracks; horrible nasty cracks with spikes and stuff at the bottom. Yurgh!

Or am I just being over sensitive?

Before I close, there are a few other confusions this deceptively short chapter threw up:

1. I thought everything in Ruby was a class. Even objects. How come then Pickaxe states "a module isn't a class" (page 119). Hmmm.
   
2. include / require / load / aaaaarhg! I like Java's "import" better and despite the problems, classpaths sheild the rest from me in 90% of situations (though heaven forbid when I have to debug a classloader problem, or worst still, implement one of my own...)
   

Ruby Has No "for" Loop - Woo Hoo!

I held onto my hat when I heard this one. I use the 'for' loop in Java a lot. Probably more than I ought. 'How will this work' I thought? No 'for' loop? Nonsense ...


When I saw it I liked it. Its often said (by me too earlier) that one of the reasons Ruby is so great is that it reads. Well, here's another example of just that. I like.

Glorious Negated "if" - "unless"

It continues! More and more comfort and joy ... Behold:


Ahhhh! A warm hug from my code.

Ruby If Expressions- Terse and Legible

More Ruby Pickaxe Learning. "if" expressions today (not "if" statements either - they return values don't you know). I was pleased to see just how terse and legible they can be:


Beautiful.