Messages to nil

[dhtapp]

Hi,

One of the things I got accustomed to in Objective C was nil's behavior as a
universal message sink: You could send nil anything, and you'd get nil
back.

No big deal, really, except that it made message cascades (which in Ruby
would look like Java- or OGNL-style keypaths) a bit easier to code, without
having to stop off at every point in the path and use an if-statement to see
if there was a real object still listening. When I switched over to
predominately using Java a few years back, it took me a couple of painful
days to change that habit (not to mention remembering to use "null"
instead...literally the most besetting annoyance I inflicted on myself in
trying to learn Java).

Just curious: would it be worth petitioning the Power That Be for a global
switch that induced that kind of behavior in nil? Would there be any
catastrophic consequences? (Please be gentle; I still have only the
faintest clue what I'm doing with Ruby, except enjoying it a great deal...)

- dan

 

[ts]

d> Just curious: would it be worth petitioning the Power That Be for a global
d> switch that induced that kind of behavior in nil? Would there be any
d> catastrophic consequences?

Well, there were some related discussion about a Null pattern, see for
example

http://www.ruby-talk.org/cgi-bin/vframe.rb/ruby/ruby-talk/17537?17391-25625
http://www.ruby-talk.org/cgi-bin/vframe.rb/ruby/ruby-talk/17721?17655-25795

(these previous URL use frame)

http://www.ruby-talk.org/17785

 

[Reimer Behrends]

dhtapp ([email protected]) wrote:
[...]

Just curious: would it be worth petitioning the Power That Be for a global
switch that induced that kind of behavior in nil? Would there be any
catastrophic consequences? (Please be gentle; I still have only the
faintest clue what I'm doing with Ruby, except enjoying it a great deal...)

Does

def nil.method_missing(*args) nil end

do what you want?

Reimer Behrends

 

[Robert Klemme]

Hi,

One of the things I got accustomed to in Objective C was nil's behavior as a
universal message sink: You could send nil anything, and you'd get nil
back.

No big deal, really, except that it made message cascades (which in Ruby
would look like Java- or OGNL-style keypaths) a bit easier to code, without
having to stop off at every point in the path and use an if-statement to see
if there was a real object still listening. When I switched over to
predominately using Java a few years back, it took me a couple of painful
days to change that habit (not to mention remembering to use "null"
instead...literally the most besetting annoyance I inflicted on myself in
trying to learn Java).

Just curious: would it be worth petitioning the Power That Be for a global
switch that induced that kind of behavior in nil? Would there be any
catastrophic consequences? (Please be gentle; I still have only the
faintest clue what I'm doing with Ruby, except enjoying it a great

deal...)

Well, instead of checking at each point you can simply catch
NoMethodError:

begin
"foo".bar.baz.foo.doit( "yes" )
rescue NoMethodError => e
puts "ERROR in method #{e.name}( #{e.args.inspect} )"
end

Btw: the same works in Java, only there you'd probably catch
NullPointerException.

Regards

robert

 

[dhtapp]

Wow, apparently so! Thanks!

- dan