Message Eating Null - article

Nevin Pratt nevin at bountifulbaby.com
Sat Jul 28 15:12:09 UTC 2007


>>
>>
> I see your point, however, I dont see that as much different to nil. 
> Have you ever found something not working because a value you expected 
> to be initialize was not, some time in the past.
>
> I am not suggesting indiscriminate use of null. It is useful in some 
> situations.
>
> In actual fact in versions prior to my latest package releases null 
> would not have been able to ignore ifTrue ifFalse anyway, it would 
> have to throw an error. Neither can it in other languages such as ruby 
> since ifTrue ifFalse are somewhat more wired in to the underlying 
> runtime than in smalltalk.
>
>
> Further more do you have any idea where in the past the initialization 
> failed to happen.
>
> With null you can find out where it started.
>

I've only just noticed this thread.  As the original author of the 
article cited, I would like to make a couple of comments:

1. As stated in the article, a message eating nil has been standard 
behavior in Objective-C (the current workhorse language on the Mac, and 
prior to that, NeXT machines).  I've *never* seen what I would call a 
genuine problem with it in this environment.

2. My use of a generalized Null object in Smalltalk (mimicking 
Objective-C) began as an experiment.  The experiment lasted many, many 
years of general use of the pattern, to see what problems, if any, 
resulted.  My conclusions from the experiment are these:

   * First of all, code should be layered-- presentation (GUI) code 
should be kept in the presentation layer, and the domain code should be 
kept in the domain layer (where the bulk of the application logic should 
reside).

   * With well-layered code, a generalized Null has *never* created a 
problem for me in the domain layer, and has *always* simplified the code.

   * I have hit issues with a generalized Null used in the presentation 
layer.  I don't, as of now, recall what the issues were, but if my 
memory hasn't completely failed, it was because the generalized Null did 
not integrate well with the existing GUI frameworks already found in all 
Smalltalk implementations.  For example, I seem to remember parts of 
certain GUI frameworks *expecting* an exception to occur as part of the 
normal GUI generating framework, and if the exception did not occur, the 
framework simply broke.  I remember frowning at this, because I think 
exceptions should only be used for exceptional circumstances, and not be 
a designed-in part of the normal processing flow of the GUI.  I can't 
give specifics now, but that is the issue that now sticks to my mind.

I'd also like to comment that had the GUI frameworks been created in a 
message-eating nil (Null) framework from their inception, the issues I 
hit would not have existed.  But in any case, I would *not* recommend 
the pattern to be used indiscriminately throughout all of your own code, 
but I also see no reason *not* to use the pattern if the pattern is 
isolated to your domain layer only.

Also, all of this experience predates any web work, and was pure 
client-server code and client-server experience.

Nevin




More information about the Squeak-dev mailing list