Nov 302006
 

I love strong typed languages.  Languages that require you to define all variables before use.  They save me from myself, or, from my attrocious spelling.  I was working on LibraryFind, OSU’s opensource metasearch service, three days ago making a few tweaks and changes.  One of the things that this tool has that is somewhat researchy — is this idea of caching all results and how that cache gets reutilized in different sessions.  Anyway, I was making a few changes to the following lines:


      #======================================================
      # Check to see if data was cached -- if it is load
      #======================================================
      if _search_id != nil
         _lxml = CachedSearch.retrieve_metadata(_search_id, _collect.id, _max.to_i)
         if _xml != nil
           if _lxml.status == LIBRARYFIND_CACHE_OK
             if _lxml.data != nil
               _lrecord =  _objRec.unpack_cache(_lxml.data, _max.to_i)
               _results_count = _results_count +  _lrecord.length
               record = record.concat(_lrecord)
               is_in_cache = true
             else
               is_in_cache = true
             end
           elsif _lxml.status == LIBRARYFIND_CACHE_EMPTY
             is_in_cache = true
           end
         end
      end


 

See what I did?  I’m sure you do.  However, I didn’t until last night when I thought that the caching service was running really slow.  So I looked in the code, and found my problem.  A typo.  It should have looked like:


      #======================================================
      # Check to see if data was cached -- if it is load
      #======================================================
      if _search_id != nil
         _lxml = CachedSearch.retrieve_metadata(_search_id, _collect.id, _max.to_i)
         if _lxml != nil
           if _lxml.status == LIBRARYFIND_CACHE_OK
             if _lxml.data != nil
               _lrecord =  _objRec.unpack_cache(_lxml.data, _max.to_i)
               _results_count = _results_count +  _lrecord.length
               record = record.concat(_lrecord)
               is_in_cache = true
             else
               is_in_cache = true
             end
           elsif _lxml.status == LIBRARYFIND_CACHE_EMPTY
             is_in_cache = true
           end
         end
      end

Since Ruby, like many scripting languages, happily created variables for you, I didn’t notice it.  And since the program kept running — abiet, more slowly — it didn’t dawn on me that I’d caused a boo-boo.  It wasn’t until last night, 2 days later, that I found it while doing a code audit.  A practice I have when dealing with scripting languages is to audit modified code weekly to inventory the life of each variable/process.  It’s something I do mostly as a way to eliminate variable useage — but in this case, it helped me find this problem.  Ack.

 

–TR

 Posted by at 10:25 am

  4 Responses to “Why I miss strong variable typing in scripting languages”

  1. I also prefer being forced to declare variables for the same reason. BTW, I noticed one other small thing in the code. The the structure:

    is_in_cache = true
    else
    is_in_cache = true
    end

    is harmless, but strange. Why not just put

    is_in_cache = true

    right outside the block since it occurs regardless of how the conditional works out. Saves 2 lines of code which is not much, but every bit helps.

  2. Wow — does Ruby not have the equivalent of Perl’s “use strict” or PHP’s “E_NOTICE”?

    And yes, it took me a little while to see the problem, but I found it. Bugs like that can drive you nutters.

  3. Ah, yes. The is_in_cache looks that way because this was revised code that wasn’t working. I’d recreated the original structure setting variables at points in the loop to make sure I wasn’t missing something stupid. And I still did. Ack.

  4. As far as I know — I don’t believe that it has an equivalent to the use strict, but that could just be because I haven’t looked hard enough. Now I’m curious. I’ll have to check and post back.

Sorry, the comment form is closed at this time.