Message Eating Null - article

---

> Date: Sat, 28 Jul 2007 09:43:15 +0200
> From: [hidden email]
> To: [hidden email]
> Subject: Re: Message Eating Null - article
>
> I think it *is* an honest argument. One of the strong points of
> Smalltalk is its readability, and that code block was awful in that
> respect.

The block itself, or you mean the #inject:into:?  If you just mean the block, then I must say that's quite a reaction!  I would certainly have switched to #ifNotNil: or something before committing it to a repository but it wasn't *that* bad.

If you mean the #inject:into: then I disagree.  To me the truly interesting thing about Smalltalk is it's beautiful mix of OO and functional programming.  I don't go around throwing #inject:into: into everything I see, but in this case the example was an obvious traversal that would either require creating a new class (as he did) or using a general operator to short-circuit a call chain if a nil shows up (since nil was an acceptable value).  In my personal opinion the #inject:into: would be more readable unless you specifically point out that a NullObject pattern is being used.  But certainly wouldn't want some preference somewhere that says "switch my image to null pattern".

Writing unreadable code does not mean using advanced features of the language/libraries to simplify something.  I would certainly choose the #inject:into over that mess with temp variables all over.  We shouldn't fear to use the power of our language.

---

Local listings, incredible imagery, and driving directions - all in one place! Find it!

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

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

Also, when you become CEO of a start-up, your perspective changes
dramatically.  As the sole tech person for bountifulbaby.com, with
whatever added functionality has been needed for the company, I have
found myself wanting and needing to get it up and running *right now*,
regardless of what the code looked like.  And this has led me down the
hacker path of ugly code, and not even caring if it was ugly.

I know that view can be dangerous.  I just wanted to point out that
perspectives can change dramatically, depending on your role, as well as
whether or not it is your own money you are playing with.

Nevin