<?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: Invalidation Strategies for Flash Player	</title>
	<atom:link href="https://jessewarden.com/2007/01/invalidation-strategies-for-flash-player.html/feed" rel="self" type="application/rss+xml" />
	<link>https://jessewarden.com/2007/01/invalidation-strategies-for-flash-player.html</link>
	<description>Software &#124; Fitness &#124; Gaming</description>
	<lastBuildDate>Sat, 10 Feb 2007 00:23:51 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		By: JesterXL		</title>
		<link>https://jessewarden.com/2007/01/invalidation-strategies-for-flash-player.html/comment-page-1#comment-4133</link>

		<dc:creator><![CDATA[JesterXL]]></dc:creator>
		<pubDate>Sat, 10 Feb 2007 00:23:51 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1122#comment-4133</guid>

					<description><![CDATA[Programming by contract goes farther than &#039;using components within yourself&#039; as Composition.  It means there ARE no base classes.  Everything is an interface, and you implement those.  Even your children can be brought in via interfaces via Factories, so as long as a child implements a specific interface, say &lt;a href=&quot;http://livedocs.macromedia.com/flex/2/langref/mx/core/IUIComponent.html&quot; rel=&quot;nofollow&quot;&gt;IUIComponent&lt;/a&gt;, he can be created within you via Composition.

&lt;a href=&quot;http://en.wikipedia.org/wiki/Object_composition&quot; rel=&quot;nofollow&quot;&gt;Composition&lt;/a&gt; is merely the pattern, in Flash / Flex terms, of using components within components (Using Button + Label in a UIComponent to make CheckBox).  There is no enforcement however unless you strongly type addChild (like it is via &lt;a href=&quot;http://livedocs.macromedia.com/flex/2/langref/flash/display/DisplayObject.html&quot; rel=&quot;nofollow&quot;&gt;DisplayObject&lt;/a&gt;).  Instead of using DisplayObject, Chris would argue to use IDisplayObject for example (which you can&#039;t btw, but it would be cool if you could).


]]></description>
			<content:encoded><![CDATA[<p>Programming by contract goes farther than &#8216;using components within yourself&#8217; as Composition.  It means there ARE no base classes.  Everything is an interface, and you implement those.  Even your children can be brought in via interfaces via Factories, so as long as a child implements a specific interface, say <a href="http://livedocs.macromedia.com/flex/2/langref/mx/core/IUIComponent.html" rel="nofollow">IUIComponent</a>, he can be created within you via Composition.</p>
<p><a href="http://en.wikipedia.org/wiki/Object_composition" rel="nofollow">Composition</a> is merely the pattern, in Flash / Flex terms, of using components within components (Using Button + Label in a UIComponent to make CheckBox).  There is no enforcement however unless you strongly type addChild (like it is via <a href="http://livedocs.macromedia.com/flex/2/langref/flash/display/DisplayObject.html" rel="nofollow">DisplayObject</a>).  Instead of using DisplayObject, Chris would argue to use IDisplayObject for example (which you can&#8217;t btw, but it would be cool if you could).</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Steven Sacks		</title>
		<link>https://jessewarden.com/2007/01/invalidation-strategies-for-flash-player.html/comment-page-1#comment-4132</link>

		<dc:creator><![CDATA[Steven Sacks]]></dc:creator>
		<pubDate>Fri, 09 Feb 2007 20:52:49 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1122#comment-4132</guid>

					<description><![CDATA[What Chris was talking to you about is a design pattern known as Composition.  I know you hate design patterns (wink) but I think you should pick up Head First and give it a go.]]></description>
			<content:encoded><![CDATA[<p>What Chris was talking to you about is a design pattern known as Composition.  I know you hate design patterns (wink) but I think you should pick up Head First and give it a go.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: JesterXL		</title>
		<link>https://jessewarden.com/2007/01/invalidation-strategies-for-flash-player.html/comment-page-1#comment-4131</link>

		<dc:creator><![CDATA[JesterXL]]></dc:creator>
		<pubDate>Thu, 01 Feb 2007 19:09:23 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1122#comment-4131</guid>

					<description><![CDATA[No, because they have no clue how the children are doing the invalidating, they just know that the children have a method called &#039;invalidate&#039; that takes no parameters and doesn&#039;t return anything.  That leaves the details of redraw up to the invidual components.]]></description>
			<content:encoded><![CDATA[<p>No, because they have no clue how the children are doing the invalidating, they just know that the children have a method called &#8216;invalidate&#8217; that takes no parameters and doesn&#8217;t return anything.  That leaves the details of redraw up to the invidual components.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Bob		</title>
		<link>https://jessewarden.com/2007/01/invalidation-strategies-for-flash-player.html/comment-page-1#comment-4130</link>

		<dc:creator><![CDATA[Bob]]></dc:creator>
		<pubDate>Thu, 01 Feb 2007 19:03:24 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1122#comment-4130</guid>

					<description><![CDATA[If parents are responsible for invalidating their children, does that break the notion of &#039;black box&#039; encapsulation?]]></description>
			<content:encoded><![CDATA[<p>If parents are responsible for invalidating their children, does that break the notion of &#8216;black box&#8217; encapsulation?</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: JesterXL		</title>
		<link>https://jessewarden.com/2007/01/invalidation-strategies-for-flash-player.html/comment-page-1#comment-4129</link>

		<dc:creator><![CDATA[JesterXL]]></dc:creator>
		<pubDate>Wed, 31 Jan 2007 23:40:25 +0000</pubDate>
		<guid isPermaLink="false">http://jessewarden.com/?p=1122#comment-4129</guid>

					<description><![CDATA[Yes, shorter variable names use less RAM, and are faster to execute (faster bytecode).  Briefly mentioned that with other optimizations in a &lt;a href=&quot;http://www.jessewarden.com/archives/2007/01/flash_lite_2_lo.html&quot; rel=&quot;nofollow&quot;&gt;previous entry&lt;/a&gt;.]]></description>
			<content:encoded><![CDATA[<p>Yes, shorter variable names use less RAM, and are faster to execute (faster bytecode).  Briefly mentioned that with other optimizations in a <a href="http://www.jessewarden.com/archives/2007/01/flash_lite_2_lo.html" rel="nofollow">previous entry</a>.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
