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 at SmallScript.com | http://www.smallscript.org


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Ned Konz
> Sent: Saturday, July 20, 2002 3:23 PM
> To: squeak-dev at 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
>