<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: NULL as a function argument should be illegal</title>
	<atom:link href="http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal/feed" rel="self" type="application/rss+xml" />
	<link>http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal</link>
	<description>The personal weblog of Peter Hosey.</description>
	<pubDate>Tue, 07 Oct 2008 18:17:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Colin Barrett</title>
		<link>http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-11609</link>
		<dc:creator>Colin Barrett</dc:creator>
		<pubDate>Sat, 10 Mar 2007 01:33:04 +0000</pubDate>
		<guid isPermaLink="false">http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-11609</guid>
		<description>&lt;code&gt;assert()&lt;/code&gt;ing on illegal pre-conditions is extremely useful (although you need to get used to looking at the top of the method for them ;). I'm not sure how asserting on post-conditions would be useful within a method: shouldn't you assert when you find an inconsistency at &lt;i&gt;any&lt;/i&gt; point, not just post-flight?</description>
		<content:encoded><![CDATA[<p><code>assert()</code>ing on illegal pre-conditions is extremely useful (although you need to get used to looking at the top of the method for them ;). I'm not sure how asserting on post-conditions would be useful within a method: shouldn't you assert when you find an inconsistency at <i>any</i> point, not just post-flight?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Smith</title>
		<link>http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9827</link>
		<dc:creator>David Smith</dc:creator>
		<pubDate>Tue, 27 Feb 2007 16:54:20 +0000</pubDate>
		<guid isPermaLink="false">http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9827</guid>
		<description>So on a related note, what do you feel about assert()ing pre- and post-conditions for methods? Obviously the technique is a lot more powerful in languages like Eiffel where it can be used at compile time to disallow broken programs, but it still seems potentially useful in other languages.</description>
		<content:encoded><![CDATA[<p>So on a related note, what do you feel about assert()ing pre- and post-conditions for methods? Obviously the technique is a lot more powerful in languages like Eiffel where it can be used at compile time to disallow broken programs, but it still seems potentially useful in other languages.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter Hosey</title>
		<link>http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9731</link>
		<dc:creator>Peter Hosey</dc:creator>
		<pubDate>Mon, 26 Feb 2007 18:36:39 +0000</pubDate>
		<guid isPermaLink="false">http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9731</guid>
		<description>Phil: Yup, I totally agree—for an &lt;em&gt;output&lt;/em&gt; (return-something-by-reference) argument, using NULL to mean “no thanks” should always be allowed.

I'll update the post later today, but I'll point out now that this really only applies to C and its descendants. Other programming languages—those with a first-class sequence type—should simply return everything in a tuple/list/array and let the caller unpack the values and throw away what he doesn't want. (Fictional Python example: &lt;code&gt;x, y = myView.frameOrigin()&lt;/code&gt;)</description>
		<content:encoded><![CDATA[<p>Phil: Yup, I totally agree—for an <em>output</em> (return-something-by-reference) argument, using NULL to mean “no thanks” should always be allowed.</p>
<p>I'll update the post later today, but I'll point out now that this really only applies to C and its descendants. Other programming languages—those with a first-class sequence type—should simply return everything in a tuple/list/array and let the caller unpack the values and throw away what he doesn't want. (Fictional Python example: <code>x, y = myView.frameOrigin()</code>)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phil</title>
		<link>http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9730</link>
		<dc:creator>Phil</dc:creator>
		<pubDate>Mon, 26 Feb 2007 18:26:59 +0000</pubDate>
		<guid isPermaLink="false">http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9730</guid>
		<description>I think you miss an important use of NULL, and one i believe to be valid.  (example from NSXMLNode)

-(NSArray *)nodesForXPath:(NSString *)xpath error:(NSError **)error

When your methods are providing a way to return additional data into a user-specified memory location, being able to optionally say "no thanks, I don't want that data" is useful, especially when following a standard model (like the NSError one).  When it comes to using NULL/nil as a data providing argument, I think you're right, however.</description>
		<content:encoded><![CDATA[<p>I think you miss an important use of NULL, and one i believe to be valid.  (example from NSXMLNode)</p>
<p>-(NSArray *)nodesForXPath:(NSString *)xpath error:(NSError **)error</p>
<p>When your methods are providing a way to return additional data into a user-specified memory location, being able to optionally say "no thanks, I don't want that data" is useful, especially when following a standard model (like the NSError one).  When it comes to using NULL/nil as a data providing argument, I think you're right, however.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Smith</title>
		<link>http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9518</link>
		<dc:creator>David Smith</dc:creator>
		<pubDate>Sun, 25 Feb 2007 21:36:44 +0000</pubDate>
		<guid isPermaLink="false">http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9518</guid>
		<description>AIContactController is (or was, before I changed some of it) a particularly flagrant abuser of this principle. It definitely tends to conceal bugs, and imo NULL arguments should probably assert.</description>
		<content:encoded><![CDATA[<p>AIContactController is (or was, before I changed some of it) a particularly flagrant abuser of this principle. It definitely tends to conceal bugs, and imo NULL arguments should probably assert.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Evan</title>
		<link>http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9508</link>
		<dc:creator>Evan</dc:creator>
		<pubDate>Sun, 25 Feb 2007 16:39:07 +0000</pubDate>
		<guid isPermaLink="false">http://boredzo.org/blog/archives/2007-02-25/null-as-a-function-argument-should-be-illegal#comment-9508</guid>
		<description>I've definitely made this mistake with NSNotificationCenter before -- observing for an object I "know" is non-NULL, then being confused when I receive notifications for everything because a buglet elsewhere had nulled the variable.  Making it illegal is a great design idea.</description>
		<content:encoded><![CDATA[<p>I've definitely made this mistake with NSNotificationCenter before -- observing for an object I "know" is non-NULL, then being confused when I receive notifications for everything because a buglet elsewhere had nulled the variable.  Making it illegal is a great design idea.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.200 seconds -->
