Nil as absorbing element

[GoogleCodeExporter]

In 80% of the cases, tests for nil in AmbientTalk source are to see whether it 
is safe to send a 
message to a variable. This boilerplate code can be avoided by allowing nil to 
absorb invocations.

Obviously support is then needed to distinguish where a nil result came from. 
In other words, if the 
result is nil as the consequence of a programming error, nil should contain the 
stack of absorbed 
calls to be able to determine where things went wrong.

Original issue reported on code.google.com by tvcut...@gmail.com on 16 Sep 2008 at 1:56

[GoogleCodeExporter]

Con: this is a dangerous language feature, because in 20% of the cases, 
you’re using nil for other purposes, 
e.g. to denote the absence of some value (consider hashmap.get(x) which returns 
nil if the key is not present).

Con: this feature works great as long as you use it intentionally as a 
programmer. I.e. somewhere in your code 
you know that a value can be nil but you’re sending messages to it anyway. 
However, in the few AT programs 
I have written, once in a while, I get a “selector not found in nil” 
exception which is ATs equivalent to a 
nullpointer exception. If these would no longer be caught, this could be a 
nightmare to debug, because the 
error does not necessarily propagate anymore, but can remain hidden and cause 
other errors in totally 
different places of the code.

Counterproposal: if you do want to have nil as an absorbing element, you could 
easily define your own anil 
object in AT which absorbs all messages sent to it. Then your code should just 
return anil instead of nil when 
appropriate. I do realise that if native code still returns nil, you’re still 
screwed sometimes.

Other counterproposal: introduce a new operator ".?" (and maybe also ^? and 
<-?) where "o.?m()" is 
equivalent to "(o==nil).ifFalse: { o.m() }".

Original comment by tvcut...@gmail.com on 16 Sep 2008 at 1:57

[GoogleCodeExporter]

PS. the .? operator exists in the Groovy language.

Original comment by tvcut...@gmail.com on 16 Sep 2008 at 1:58