[deadbadger]

On the subject of try() chaining, there's always Ick, which implements (among other things) a kind of Maybe monad for Ruby. This acts as a self-propagating nil guard, so you're able to write things like:

  maybe(Person.find("geoff")) { |person| person.manager.authority_level.permissions }

without worrying about chaining things yourself. I've not used it in production code yet, as I haven't really had a chance to do due diligence on it - be interested to hear if anyone else has used it in anger...

http://ick.rubyforge.org/

[tomstuart]

Even better to avoid chaining altogether by using delegation (cf. Law of Demeter) and taking advantage of the :allow_nil option to Active Support's Module#delegate (http://api.rubyonrails.org/classes/Module.html#method-i-dele...).

[gecko]

There's a solution in Smalltalk that I'm wondering why no one's brought to Ruby. In applications where this pattern is useful, there's a class, Null, with the singleton null (in contrast to UndefinedObject and its singleton nil). nil raises an exception, but null simply eats all messages sent to it, much like the maybe monad you listed.

This makes it really easy to mix and match the two paradigms in your code: in places where it's okay for the object to just eat messages, you return null. In places where no value is a real error, you return nil. Either value can be converted to the other with a one-line statement, and to existing code, null looks like nil when queried (i.e., isNil returns true, ifNil: and ifNotNil: and friends behave as if null were nil, etc.).

Seems as if writing a similar tool for Ruby would be trivial.

[deadbadger]

But then don't you have to make your choice about whether no-value is an error when you return the value, rather than when you make the call?

With #try et al it's made obvious at the point the message is sent whether it'll be swallowed by nil (and that you're fine with this). To me this seems safer than having two classes of entities knocking round, one swallowing messages and one not, and no way to tell at a glance which is which.

(I've not used Smalltalk btw, so apologies if I've misunderstood...)

[gecko]

You can use it either way. I usually employ it at return time, because usually there are classes (little-case C) of return types that I'm fine with being ignored. A list of objects that need to be signaled on an event, for example: it's fine with me if that's not initialized, so it's okay to return null there.

Sometimes, you want to do what you're saying, and have a brief snippet where you switch to message-eating null. That's easy enough using the built-in ifNil: message:

    (foo ifNil: [ null ]) baz quux frob: bar.

If this is common, it'd be easy to add a method "try" to Object that returned self, and one to UndefinedObject that returned null, at which point you could do the same thing as Ruby:

    foo try baz quux frob: bar.

So either way, really.

[_pius]

The Null Object pattern is used in RSpec and some other testing libraries for mocks.