Ahh, the Subtleties of Ruby's Operator Precedence

Rick DeNatale — Tue, 07 Aug 2007 15:24:00 -0400

Not long ago while working on an existing Rails application, (i.e. code I hadn’t written). I was mystified when a logical expression seemed to be returning an odd result. The expression had been written with not, and, and or, and was the right hand side of an assignment statement. ventually I changed to using !, &&, and || which fixed the problem. I never completely understood what was going on, until I encountered this blog entry by Jay Fields.

One of the big differences between Ruby and Smalltalk is the use of operator precedence. In Smalltalk, the grammar is very simple, unary message selectors bind tighter than binary selectors, which bind tighter than keyword selectors. The assignment operator binds more loosely than any of these. This is often a stumbling block for newcomers to Smalltalk when they find that in Smalltalk 3 + 5 * 2 evaluates to 16.

Ruby in comparison has quite a rich and flexible syntax. Usually, it’s quite intutitive, but, depending on where you come from there can be some surprises.

I understood the relative precendences of, say && vs. and in Ruby, but the fact that and had weaker precedence than = escaped me, until Jay’s article turned the light on for me.

As they say, you learn something new everyday, or at least you hope you do. I don’t expect that I’ll forget this little corner of Ruby in future

Qui ipso probo probatur?

Rick DeNatale — Sat, 14 Jul 2007 15:28:00 -0400

The other day I was working on adding support for user selected time-zones to an existing rails app for a client. As usual I was doing test-first development. One of the things that makes rails such a pleasure is that a good set of tests give confidence that you aren’t breaking “legacy” code.

I also use, and really like, the rails plugin for vim which does lots of nice things like making navigation between the files of rails apps much easier. It also has a nice feature which adds a :Rake command to vim which “does the right” thing contextually. For example if you are editing a migration and enter :Rake, it runs rake db:migrate. If you are in a test file it runs just the single test selected by the cursor, or just that test file if you aren’t positioned to a particular test.

I was doing the latter, and my test was failing, and I was having a hard time debugging it. I tried executing just that single test from the bash command line with:

$ruby test/unit/my_test.rb -n"test_mytest"

and it still failed, no surprise. The same thing happened if I ran the entire test file, in fact, other tests which had worked before were now failing, and I was really mystified now because I didn’t see how I had done anything which had a remote chance of breaking those.

So I figured I probably should test everthing so:

$rake test

And, surprise of surprises, but every test worked. Not only my failing unit tests, but the functional and integration tests as well.

To make a long story short, the problem turned out to be that the tests were failing because, now that the particular model was sensitive to the user’s timezone, it needed access to it’s associated user model, and I hadn’t told the testcase that the users fixture was needed. Running the testcase in isolation, the users table wasn’t being populated for the test case. But running rake test, or rake test:units meant that other tests run before had left the data I needed behind.

Just a little thing that makes fixtures less than ideal.

Talk Like A Duck: Tag gotchas

Ahh, the Subtleties of Ruby's Operator Precedence

Qui ipso probo probatur?