Marcel Weiher wrote:
But, since the only "classic Smalltalk" solution is to make "black-hole" messaging system/image wide, then it becomes quite troubling when any thought is given to teams of people integrating code which may come from unrelated parties and their distinct frameworks.
I don't see any validation for your claim that this becomes troubling. None whatsoever. I just have evidence to the contrary.
Marcel
It's difficult to integrate other people's code when the "other" people write code like this:
[foo bar someMessage] on: MessageNotUnderstood do: [:ex | foo fum].
And, that kind of code is actually quite common to see.
In this case, if #bar returned a message-eating nil, then the #fum method never executes, and the application probably expected it to. That's one of the problems with introducing message-eating nils into the existing code base.
With message-eating nil behavior, the above could have been written thus:
foo bar someMessage isNil ifTrue: [foo fum].
...which interestingly enough once again is simpler than the original code.
If it weren't for the need to adopt the pattern layer-wide and uniformly, I too am convinced there is nothing wrong with the pattern, and firmly side with Marcel.
It's when the pattern has to co-exist with code written by people who expected the other (exception throwing nil) behavior where it gets into trouble.
Nevin