TITLE: Two Patterns Dealing with Side Effects
AUTHOR: Eugene Wallingford
DATE: June 13, 2008  3:55 PM
DESC: 
-----
BODY:
I ran across a pattern today that reminded of another
I encountered
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2008-03.html#e2008-03-19T00_40_23.htm">
   while at ChiliPLoP</A>.
Both help developers deal with <EM>side effects</EM>,
changes to a program's state.  Let me share these
patterns with you all, with a common explanation of
their value.

Most programs written these days are in a style where
setting and changing the values of one or more variables,
via a sequence of imperative statements.  Side effects
are a common source of programmers' misunderstanding
when reading code.  A program can change a variable's
state almost anywhere, and that makes reading any bit
of code uneasy:  "Do I really know what this variable
means right now?"  Using only local variables only in
the context of a small procedure is one way to localize
effects.  Even still, problems can arise.

I won't try write full patterns for these.  I'll write
short patlets and give you links to the articles I read,
which do a good job talking about the ideas.

<STRONG>Mutual Recursion with Side Effects</STRONG>

In
<A HREF="http://norvig.com/sudoku.html">
   Solving Every Sudoku Puzzle</A>,
Peter Norvig builds a Python program for the title task.
About 40% of the way in, he says:

<BLOCKQUOTE><EM>
If you have two mutually-recursive functions that both
alter the state of an object, try to move almost all
the functionality into just one of the functions.
Otherwise you will probably end up duplicating code.
</EM></BLOCKQUOTE>

Duplicate code is usually a bad thing, because it creates
a problem for programmers keeping the copies in sync.
Duplicate code that modifies state is especially bad,
because it brings in the extra complication of making
<EM>another</EM> procedure harder to understand.

<STRONG>Side Effects and Python's Default Parameters</STRONG>

Coincidentally, the second pattern involves Python, too.
This time the pattern is Python-specific, addressing
an issue with a language feature.

<I>Context</I>: You are writing a procedure with a
default parameter.

<I>Problem</I>: The procedure needs to modify the
default parameter.  Python evaluates a default parameter's
initial value only on the first call to the procedure.

<I>Solution</I>: Whenever the parameter is missing,
initialize it within the method.

Tim Ottinger gives his implementation technique in
<A HREF="http://blog.objectmentor.com/articles/2008/05/22/pythons-mutable-default-problem">
   Python's Mutable Default Problem</A>:

<PRE>
def function( item, stuff=None ):
   stuff = stuff or []
   # ... modify stuff, etc.
</PRE>

This pattern allows the user to take advantage of the
default parameter when he has no collection to send.
It does so by following a principle laid out in the
<A HREF="http://www.siafoo.net/article/52#default-argument-values-are-only-evaluated-once">
   article Ottinger references</A>:
In Python, "don't use mutable objects as function defaults."

This pattern may not be Python-specific, because there
may be other languages with this initialize-once behavior.
It seems like a bug to me, not a feature, but I'm not a
Python programmer and so can't speak authoritatively.
But I am glad that
<A HREF="http://www.cs.uni.edu/~wallingf/blog-images/code/mutable-default-parameter.rb">
   Ruby doesn't do this</A>.

~~~~~

<B>Postscript</B>:  While preparing this article, I learned
something new about Ruby, unrelated to this issue.
It is possible to extract from a class a new class that
has a
<A HREF="http://rubylution.ping.de/articles/2005/12/21/rubys-rich-array-api">
   subset of the original class's protocol</A>.
Very nice indeed!)
-----