3 ms·

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 := p

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.

masklinn 5y ago
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.
- tangus 5y ago
  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.
  - deleted 5y ago
    [deleted]
- nielsbot 5y ago
  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...

masklinn 5y ago

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.

tangus 5y ago
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.
- deleted 5y ago
  [deleted]
nielsbot 5y ago
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...