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" == dhtapp <dhtapp@cox.net> writes:

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/vfr...37?17391-25625
http://www.ruby-talk.org/cgi-bin/vfr...21?17655-25795

(these previous URL use frame)

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


--

Guy Decoux

[Reimer Behrends]

dhtapp (dhtapp@cox.net) 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]

"dhtapp" <dhtapp@cox.net> schrieb im Newsbeitrag
news:2c6sb.12896$7B2.12145@fed1read04...

> 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

"Reimer Behrends" <behrends@cse.msu.edu> wrote in message
news:slrnbr1tqv.kts.behrends@ellington.cse.msu.edu ...

>
> def nil.method_missing(*args) nil end
>
> do what you want?
>
> Reimer Behrends