One problem was that there were multiple databases, each with their own data.   By the time the issue was discovered, a fix was needed soonest, so the solution was less than elegant, but it does illustrate the use of callbacks in ActiveRecord:

module DbParanoia
# This is a really stupid thing to have to back-fit; it is making
# sure, however, that the users enter good data. We ensure that
# strings are stripped on read and write.

alias_method :after_find, :trim_space
alias_method :before_save, :trim_space
end


The above module is using the after_find and before_save callbacks to make sure that:

1. Any spaces coming back from the database are trimmed.
2. Any new records and/or updates will have the spaces trimmed.

You can use this method to perform pretty much any sort of validation or data manipulation of the data of an ActiveRecord class.  Other callbacks include:

• after_create
• after_destroy
• after_save
• after_update
• after_validation
• after_validation_on_create
• after_validation_on_update
• before_create
• before_destroy
• before_save
• before_update
• before_validation
• before_validation_on_create
• before_validation_on_update

You can read more about ActiveRecord::Callbacks at http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html.

For example (and this came up as the result of a question on the ruby talk  mailing list), one of the things you can do is obtain a list of the local variables of a method:

def my_vars(a)
b=a
c=b+a
puts local_variables
end

returns the three variables, a, b, and c.  That’s fine, we’re still within the scope of the method.  But how about outside of our method?  This is where #binding and the Binding class come into play:

def outside(b)
puts eval("local_variables", b)
end

def my_vars(a)
b=a
c=b+a
outside(binding)
end

One thing to note: in order to work with the binding, we have to #eval code within its scope.  Thus the call to #eval with the method we are invoking and the binding.  This leads to the question from the mailing list:

we already have #has_block? to see if a block was passed. So how about
a #has_arguments? to query if _any_ arguments have been passed — Intransition

So how would we go about writing a #has_arguments? — here is a first stab:

class Object
def has_arguments?(b)
vars = eval("local_variables",b)
return false if vars.length == 0
vars.each do |v|
return false if eval("#{v}.nil?",b)
end
return true
end
end

class Foo
def initialize(first=nil)
if (has_arguments? binding)
puts "We're defined"
else
puts "Not!"
end
end
end

The only real drawback here is that we’ve got to pass in the binding itself.  Let’s try again:

class Object
def has_arguments?(&b)
vars = eval("local_variables",b.binding)
return false if vars.length == 0
vars.each do |v|
return false if eval("#{v}.nil?",b)
end
return true
end
end

class Foo
def initialize(first=nil)
if (has_arguments? {}) # note the empty block
puts "We're defined"
else
puts "Not!"
end
end
end

In this case, instead of explicitly calling #binding, we’re passing in an empty block — the block has it’s own scope, but it happens to contain the scope of then enclosing method.  It’s still not perfect, however:

1. You need to pass in an empty block.
2. It fails if you have local variables other than those passed in as arguments. (Pointed out by Joel VanderWerf)

Ok, it’s got some serious flaws (Charles Nutter posted a different way of solving the problem, which does work for all cases, and doesn’t use #binding).  But it does give an idea of what you can do with #binding.

Let’s take a look:

$ irb
>> class Foo
>> end
=> nil
>> f=Foo.new
=> #
>> f.i_do_not_exist
NoMethodError: undefined method `i_do_not_exist' for #
from (irb):5
>> class Foo
>> def method_missing(symbol,*args)
>> if (symbol.to_s === "i_do_not_exist")
>> puts "Yes, actually you do"
>> end
>> end
>> end
=> nil
>> f.i_do_not_exist
Yes, actually you do
=> nil
>> f.i_exist
=> nil

Unfortunately, we no longer get the error when we try to invoke a method which does not exist.  When we add an invocation to super, it’ll behave as expected:

>> class Foo
def method_missing(symbol,*args)
if (symbol.to_s === "i_do_not_exist")
puts "Yes, actually you do"
else
super
end
end
end
>> >> >> >> ?> >> >> >> => nil
>> f.i_exist
NoMethodError: undefined method `i_exist' for #
from (irb):31:in `method_missing'
from (irb):35
>> f.i_do_not_exist
Yes, actually you do
=> nil
>>

One of the neat things about ruby is that, in general, operators are methods, so they can be overridden.

When working with multidimensional arrays, some languages allow you to do the following:

a[0,0]

whereas ruby uses:

a[0][0]

Which makes sense, since Ruby implements it as an array of arrays and you’re chaining methods to get to the element. But, since we can override the [] method, we can then say a[0,0].

class Grid
attr_reader :cols, :rows

end

So, it can be used like this:

$ irb
>> require 'grid'
=> true
>> g=Grid.new
=> #< Grid:0xb747d760 @cols=1, @rows=1, @grid=[[nil]] >
>> g=Grid.new(2,2)
=> #< Grid:0xb747bb04 @cols=2, @rows=2, @grid=[[nil, nil], [nil, nil]] >
>> g=Grid.new(2,2,0)
=> #< Grid:0xb7479aac @cols=2, @rows=2, @grid=[[0, 0], [0, 0]] >
>> g=Grid.new(2,2,String)
=> #< Grid:0xb7477810 @cols=2, @rows=2, @grid=[["", ""], ["", ""]] >
>> g=Grid.new(2,2,false)
=> #< Grid:0xb74755d8 @cols=2, @rows=2, @grid=[[false, false], [false, false]] >
>> g[0,0]
=> false
>> g[0,0]=true
=> true
>> g
=> #< Grid:0xb74755d8 @cols=2, @rows=2, @grid=[[true, false], [false, false]] >

It’s an interesting technique — and given that most people think of arrays/coordinates in pairs, I think that it can make the code more “readable”.

To paren, or not to paren: that is the question:

Whether ’tis nobler in the mind to suffer

The bugs and errors of maintenance programs,

Or to take arms against a host of typos,

And by debugging end them? To hack: to slash;

No more; and by a slash to say we end

The heart-ache and the thousand natural shocks

Of cut and paste code, ’tis a maturation

Devoutly to be wished. To hack, not slash;

Not slash: perchance to code: ay, there’s the rub;

For in that new programme what code may come

When we have shuffled off this unix box,

Must give us pause: there’s the respect

That makes wuffy of so long life;

– Not William Shakespeare

There’s been a good deal of conversation of late on comp.lang.ruby as to whether or not to use parentheses. And when to use them. Ruby is such that parentheses are optional, except, of course, when they’re not. Here’s some examples of where they are not:

irb(main):002:0> "parenthesis".length()
=> 11
irb(main):003:0> "parenthesis".length
=> 11

Notice that Ruby also doesn’t care if you use parenthesis or not for the arguments; in this case it doesn’t matter whether or not the parenthesis are there, because the meaning is clear, at least to the compiler. And now, for something completely different, an instance where meaning is not clear to the compiler.

irb(main):016:0> class Foo
irb(main):017:1> def fud(thing)
irb(main):018:2> thing.reverse
irb(main):019:2> end
irb(main):020:1> end
=> nil
irb(main):021:0> f.fud "hi"
=> "ih"
irb(main):022:0> f.fud "hi" ? true : false
(irb):22: warning: string literal in condition
NoMethodError: undefined method `reverse' for true:TrueClass
from (irb):18:in `fud'
from (irb):22
from /usr2/jest/tools//lib/ruby/site_ruby/1.8/rubygems/dependency.rb:19
irb(main):023:0> f.fud("hi") ? true : false
=> true


In the first instance, it is trying to evaluate
"hi" ? true : false
and then pass it to f.fud. This doesn’t work very well, since true does not have a reverse method. We’re running into an issue of order of operation. However, when we do
f.fud("hi") ? true : false
then we are successful. “hi” can be reversed and the result can be checked for non-nil-ness. In this (admittedly simplistic) example, the parenthesis were needed in order to achieve a satisfactory result.

In terms of background, I learned C 20 years ago. I cut my teeth on basic back in 1980. So I’ve been around for a little while. I mention this because several posters mentioned that one’s preference for using parenthesis may depend on one’s background, with those who come from C potentially more likely to use parenthesis whether they were needed or not.

I am of the opinion that parenthesis can make the code harder to read.
attr_accessor :first, :last
has_many :pets
is easier to my eyes and far easier to read as it mimics “natural” language than
attr_accessor(:first, :last)
has_many(:pets)
However, I realize that it is a personal choice. So my rule of thumb is to not use parenthesis, except where there is a question of clarity. I think that writing clear, maintainable code is more important than adhering to a rule of always using parenthesis. I like that Ruby, like Unix, generally has more way than one to do a thing. I understand that there are people who prefer one way of doing a thing. For those people, there’s Python. I’m kidding, of course — you can adhere to doing things a single way, such as always using parenthesis, in Ruby. To me, however, it would lessen my enjoyment of the language. And I write code in Ruby because it makes me happy to do so.

So, what do you think? Is there a compelling reason to use parentheses?

class Object
def my_methods
(self.methods - Object.methods).sort
end
end
I have since had the idea of extending it — now you can also choose to see only the methods which are implemented by an object’s Class. You can see it in use here (code at the end):
$ irb
>> class Object
>> def my_methods(_super=false)
>> _methods = (_super) ? self.class.superclass.new.methods : Object.methods
>> (self.methods – _methods).sort
>> end
>> end
=> nil
>> class Foo < String
>> def fud
>> puts “fud”
>> end
>> end
=> nil
>> f=Foo.new
=> “”
>> f.my_methods
=> ["%", "*", "+", "<<", "[]“, “[]=”, “all?”, “any?”, “between?”, “capitalize”, “capitalize!”, “casecmp”, “center”, “chomp”, “chomp!”, “chop”, “chop!”, “collect”, “concat”, “count”, “crypt”, “delete”, “delete!”, “detect”, “downcase”, “downcase!”, “dump”, “each”, “each_byte”, “each_line”, “each_with_index”, “empty?”, “entries”, “find”, “find_all”, “fud”, “grep”, “gsub”, “gsub!”, “hex”, “index”, “inject”, “insert”, “intern”, “is_binary_data?”, “is_complex_yaml?”, “length”, “ljust”, “lstrip”, “lstrip!”, “map”, “match”, “max”, “member?”, “min”, “next”, “next!”, “oct”, “partition”, “reject”, “replace”, “reverse”, “reverse!”, “rindex”, “rjust”, “rstrip”, “rstrip!”, “scan”, “select”, “size”, “slice”, “slice!”, “sort”, “sort_by”, “split”, “squeeze”, “squeeze!”, “strip”, “strip!”, “strip_tags”, “sub”, “sub!”, “succ”, “succ!”, “sum”, “swapcase”, “swapcase!”, “to_f”, “to_i”, “to_str”, “to_sym”, “tr”, “tr!”, “tr_s”, “tr_s!”, “unpack”, “upcase”, “upcase!”, “upto”, “zip”]
>> f.my_methods(true)
=> ["fud"]
>>

Here’s the promised code:
class Object
def my_methods(_super=false)
_methods = (_super) ? self.class.superclass.new.methods : Object.methods
(self.methods - _methods).sort
end
end


# I am including gems in my irb session. Therefore, the next require
require 'rubygems'

# strip html tags from a string
class String
def strip_tags
self.gsub(/<\S[^><]*>/,"")
end
end

I’ve shown mine. Show me yours?

Here are links to the referenced rubygems:

• what_methods
• map_by_method
• wirble