Animorphic ST (Strongtalk) released!
David Simmons
David.Simmons at smallscript.com
Sun Jul 21 07:24:10 UTC 2002
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
>
More information about the Squeak-dev
mailing list
|