<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: To Enum or Not to Enum</title>
	<atom:link href="http://www.potentialgames.com/blog/2008/06/25/to-enum-or-not-to-enum/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.potentialgames.com/blog/2008/06/25/to-enum-or-not-to-enum/</link>
	<description>Notes of a Potential Independent Game Developer</description>
	<lastBuildDate>Sat, 01 May 2010 13:27:33 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: neb</title>
		<link>http://www.potentialgames.com/blog/2008/06/25/to-enum-or-not-to-enum/comment-page-1/#comment-197</link>
		<dc:creator>neb</dc:creator>
		<pubDate>Thu, 26 Jun 2008 19:21:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.potentialgames.com/blog/?p=64#comment-197</guid>
		<description>As a counter-example, I&#039;m still loading terrain types from an external config file. This is simple enough, because the terrain logic (just a navigability check, at this point) does not need to know the specific terrain type.</description>
		<content:encoded><![CDATA[<p>As a counter-example, I&#8217;m still loading terrain types from an external config file. This is simple enough, because the terrain logic (just a navigability check, at this point) does not need to know the specific terrain type.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: neb</title>
		<link>http://www.potentialgames.com/blog/2008/06/25/to-enum-or-not-to-enum/comment-page-1/#comment-195</link>
		<dc:creator>neb</dc:creator>
		<pubDate>Wed, 25 Jun 2008 19:11:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.potentialgames.com/blog/?p=64#comment-195</guid>
		<description>Thanks for the corroborating report. I&#039;m glad I&#039;m not the only one.

I&#039;m currently stripping out dozens of lines-of-code and replacing them with ShopType { WEAPONSMITH } ... so much simpler. I love deleting crufty code.</description>
		<content:encoded><![CDATA[<p>Thanks for the corroborating report. I&#8217;m glad I&#8217;m not the only one.</p>
<p>I&#8217;m currently stripping out dozens of lines-of-code and replacing them with ShopType { WEAPONSMITH } &#8230; so much simpler. I love deleting crufty code.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Todd</title>
		<link>http://www.potentialgames.com/blog/2008/06/25/to-enum-or-not-to-enum/comment-page-1/#comment-194</link>
		<dc:creator>Todd</dc:creator>
		<pubDate>Wed, 25 Jun 2008 18:50:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.potentialgames.com/blog/?p=64#comment-194</guid>
		<description>We ran into this on our current project.  We wanted to make it possible to drop in a new data source without changing code, so we defined metadata files that describe the data structure.  But we still have to write code to access those data sources and so we needed a way to enumerate them in code.  And so that&#039;s what we did.  Now we maintain the data structure in two places.  

Going to exclusively using enums now seems like the better choice.</description>
		<content:encoded><![CDATA[<p>We ran into this on our current project.  We wanted to make it possible to drop in a new data source without changing code, so we defined metadata files that describe the data structure.  But we still have to write code to access those data sources and so we needed a way to enumerate them in code.  And so that&#8217;s what we did.  Now we maintain the data structure in two places.  </p>
<p>Going to exclusively using enums now seems like the better choice.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
