This post originated from an RSS feed registered with Ruby Buzz
by Rick DeNatale.
Original Post: You Can't Judge a Book... Some Mental Traps in Learning Ruby
Feed Title: Talk Like A Duck
Feed URL: http://talklikeaduck.denhaven2.com/articles.atom
Feed Description: Musings on Ruby, Rails, and other topics by an experienced object technologist.
Many beginning, and intermediate, rubyists whould instinctively say Array! The real answer is that given just this code, you don't know.
Recently, on the rails-talk mailing list there was a discussion of this idea from Jamis Buck. Jamis uses alias_method in ActiveRecord::Base so that he can use shortcuts like:
Person[1]
as a shortcut for:
Person.find(1)
This is particularly nice when playing with ActiveRecord in the rails console, but many seem to think that this should be made part of Rails core, and I don't see a real objection.
Now one objection raised by the folks who answer Array to the opening question is that, since ActiveRecord rows can be deleted, Person[2] might fail even though Person[1], and Person[3] work. The reasoning is that the [] makes it "look like an array" and arrays don't act like that.
To me this is a case of judging a book by looking at it's cover. Something which I strongly suggest needs to be resisted in order to achieve ruby mastery.
Let's have a look at a couple of "can't see past the cover" traps in Ruby.
Trap Number 1: Confusing Calling Interface with Class
Seeing a[2] and thinking Array is an example of this. Just because 99% of the time when you see something "indexed" by an integer, that thing doesn't have to be an Array. It might be an Array, but it could be a Hash, or an ActiveRecord class, or anything which implemented some form of [] method. This is looking at the method invocation as a 'cover.'
Ruby method signatures are quite a bit more flexible or at least different from those of other languages, something which can trip up someone trying to see Ruby from the perspective of their 'native' language. Consider the varieties of parameters which can be passed to Array#[], or String#[], rather than just a indexing methods these can slice and dice the receiver in various ways
Although different classes might all implement a [] method, and while there are likely similarities or common subsets of functionality, each has it's own quirks. This can drive folks expecting type signatures nuts, but it's actually one of the things which gives Ruby it's power, and efficiency of expression.
Some folks go to great efforts trying to pin-down Ruby and make it 'behave' like other languages, but that's a fools errand which works against Rubys strengths. I'd recommend that these folks redirect their efforts towards improving their testing skills.
Trap Number 2: Ignoring the Contents
For better or worse, many Ruby classes provide functions which may not work for all instances. For example, the Range (1..10) is enumerable while (1.0..10.0) is not. This is because some of the methods in range expect the beginning and ending values of the range to implement methods such as #succ in order to determine the next value. Further they implicitly expect that applying #succ successively will get to the end value.
So does this mean that making the range (1.0..10.0) is ilicit or bad? Not if you don't need to enumerate it and only want to do things like check whether or not a value is included in the range.
Some folks on ruby-talk have expressed the opinion that the documentation for Range implies that (1.0-10.0) is not a valid range, because the scope of the requirement for elements to implement #succ is ambiguous. Pragmatically I find the ability to construct enumeration challenged ranges useful.
Further if you take the philosophy which leads to restricting ranges to elements which make the ranges enumerable consider these things:
%w(Now is the time).sort# Works fine[:fee,:fie,:foe,:fum].sort# Fails ['fred',42].sort# Fails
Now do we really want to outlaw arrays of symbols, or heterogeneous arrays from Ruby usage because they don't sort?
Previous Topic
