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
|