I think the general pattern of allowing <nil> to silently eat arbitrary messages sent to it is a dangerous (*bad*) practice.
On the other hand, it is very useful and convenient to give <nil> special functionality.
A common set of patterns I've used over the years include:
a) The #? binary-message selector for #ifNil: b) the !? binary-message selector for #ifNotNil:
See, comments in c.l.s. last week on this very topic. ====
Within SmallScript, one has "selector namespaces" and the option to provide fully managed behavior on any object.
Thus, one can write things like:
Module name: MyPrivateStuff.
Class ref:name: UndefinedObject method-scope: module { Method [someSelectorA] Method [someSelectorB] Method [someSelectorC] Method [someSelectorD]
"" Or a general sink Method [delegate: selector withArguments: args] }
The key here, is that none of these modifications to <UndefinedObject> will be accessible, except from methods that have access to <MyPrivateStuff>.
That means 3rd party code running in the same environment will not have access to your "module" scoped methods within <UndefinedObject>.
Thus, any "black-hole" behavior with regard to messages to <UndefinedObject> is constrained to the code you wrote within your project/module. ----
Additionally, you could make use of warnings to log inadvertent misuse, perhaps only doing so on first occurrence and then creating a module-scope method within UndefinedObject (on the fly).
Warning name: MyNilSinkWarning { "" Write default handler code to log and "" create methods on the fly here... }
Method behavior: UndefinedObject scope: module [ delegate: selector withArguments: args ^MyNilSinkWarning.throw({selector, args}). ]
FYI: A warning is a superclass of <Exception>, and is informational which means it gets logged, but does not halt a program. A <Signal> is the superclass of <Warning>, and it too is informational, but does not get logged.
-- Dave S. [SmallScript Corp]
SmallScript for the AOS & .NET Platforms David.Simmons@SmallScript.com | http://www.smallscript.org
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Ned Konz Sent: Saturday, July 20, 2002 3:23 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Animorphic ST (Strongtalk) released!
On Saturday 20 July 2002 02:24 pm, Andreas Raab wrote:
I haven't been around during the clone (err... message-eating nil) wars but after reading your paper it makes me wonder if anyone actually ever _tried_ to use a message eating nil (and not just reason about it) in Smalltalk.
Yes, there was at least one article that I'd read on the web from a Well Known Name In Smalltalk that discussed this as a good idea. Forget who, though. Perhaps it was Alan Wirfs-Brock? Jan Steinman?
I remember making one and using it for a while several years ago. I don't remember how it turned out, though.
You do have to watch out for "== nil" (and #ifNil: #ifNotNil: etc. that end up doing "== nil"). There's a mixture of
isNil ifTrue: (which would work, as it's a message send) == nil ifTrue: (which wouldn't work) ifNil: (which also wouldn't)
etc. in Squeak.
I know that Kent Beck has mentioned in some of his discussions about the Chrysler accounting system that using custom nil objects (i.e. NilEmployee) was helpful. I believe, though, that these were not message-eaters, but just harmless dummy objects.
-- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE