I see the author's point, but I think the discussion is moot if you add nice syntax for explicitly handling `nils`.

So the author's example:

  lastNumber := person office phone lastNumberDialed asString.

Could maybe look something like

  lastNumber := person? office? phone? lastNumberDialed? asString.

Now you have neither "message eating" nor "exception throwing" nil. And the programmer is in control of what happens if other behavior is desired.

How is that supposed to work though?

Is that a modifier on existing messages (requires altering the entire language, and I don't see how it's going to work with keyword messages), or is that a binary message returning a "message-eating" proxy object?

Subsidiary question for (2), how do you handle Pharo apparently already having a `?` operator?

That aside, I think an interesting path would be to leverage conditions, assuming `#doesNotUnderstand:` can get a restart for that. Though obviously it has stack depth implication, and I've not played with conditions enough to remember whether you can get that information from a handler.

In the last 20 years people realized that the decision of of having nil eat or throw is better made by the caller. To that purpose, several languages already added a `.?` operator.

That's something that can work also in Smalltalk: Add a class `MessageEatingNil` that returns `nil` to everything except `isNil` and maybe `ifFalse`. Add a method `?` to the root class that returns self. Override that method in the Nil class to return a MessageEatingNil object.

   lastNumber := person ? office ? phone ? lastNumberDialed ? asString.

I am saying maybe the language should consider more radical changes... But I see another comment proposes how this could work in the existing scheme...

Worked with a coder who thought the correct return value from a DB with no data was the literal string vallue 'null' and so had tests for != 'null' coded everywhere, alongside != '' and != None cases.

I totally get it, when you've only ever seen DB responses via the command prompt which promotes null/nil fields to words, without any symbols to show its a textual reference, not the literal DB state.

And yes, we wound up with DB rows having the word 'null' written back into previously nil/null values.

Actual page title is "Null" and the subheading is "Message Eating Null package for Squeak". But the bulk of it is actually the article which is on the message eating null (or nil) in the context of Smalltalk and Objective-C.

I came across this while looking for a Smalltalk connection to Objective-C's behavior with nil, which is being discussed here: https://hackernews.hn/item?id=31202292

Go also allows you to write nil-processing behaviour in your types:

   func (t MyType*) process(a int, b int) { ... }
   ...
   var example *MyType
   example.process(1,2)

Will call the process method, even though the receiver is nil!

I'm not sure my brain is quite wired to cope with it yet though.

It can be useful when there is a piece of functionality that could be or not be present depending on the configuration. Something like a debug logger that is nil in a release build or some OS-dependent feature handler that is only non-nil on that particular OS. I do admit, though, that that might be confusing for people coming from languages like C++, where calling methods of null pointers is almost always an error.