Hacker News Reader

Comment by nielsbot | Hacker News Reader

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.

View on HN

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...

Reply on news.ycombinator.com