Jeff Pritchard wrote:

> I'm a relative newbie.  I'm finally getting the hang of some of the
> syntactic sugar provided, such as the whole thing about using the "or"
> operator to provide a default value if something is nil:
>
> foo = bar || "emptiness"

Please reserve the term "syntactic sugar" for cutesy systems that don't 
provide for lean and incredibly expressive statements that scale very well!

> If I have a string of stuff like:
> blah = foo.bar.split
>
> what if bar is nil?

Large scale, look up something called the "Null Object Refactor". (And note 
it's a refactor, not a pattern!)

Then implement it, small scale, like this:

  blah = (foo.bar || '').split

> I would like to be able to write:
> blah = foo.bar||empty(bar).split

Oooh, at a guess, we could go long-winded again:

  blah = (foo.bar || OpenStruct.new(:split => '')).split

> But that requires a well known object type for bar.

Are you coming from Java? Look up "Duck Typing". The /de-facto/ type in our 
statement flows right-to-left, not left-to-right like in Java. We need a 
thing that can be split, so we get it from a mock object or from .bar. Right 
to left.

There might be some way to reduce my OpenStruct experiment. I use that 
trick, not small-scale, but large scale, for example with a website that can 
entertain both logged-in users and un-logged-in guests. The former don't 
deserve a real User model record, so they get an OpenStruct object that 
provides the minimum User behavior.

Then I hide this OpenStruct. So you should next think about putting your || 
nil detector _inside_ that bar.

You can generally always get inside a method!

-- 
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax