<?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: Zhang: PacMan Tutorial</title>
	<atom:link href="http://fxexperience.com/2009/06/zhang-pacman-tutorial/feed/" rel="self" type="application/rss+xml" />
	<link>http://fxexperience.com/2009/06/zhang-pacman-tutorial/</link>
	<description>Sharing the Experience of JavaFX</description>
	<lastBuildDate>Tue, 27 Jul 2010 23:34:04 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Richard</title>
		<link>http://fxexperience.com/2009/06/zhang-pacman-tutorial/comment-page-1/#comment-71</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Thu, 16 Jul 2009 14:37:27 +0000</pubDate>
		<guid isPermaLink="false">http://fxexperience.com/?p=71#comment-71</guid>
		<description>Ah, but what if every node had a map, and such a map would fire binding events. Further, what if each map&#039;s elements were treated as a type of dynamic property? In this case, you would get the benefits of the second purpose without having to subclass, and without the cost of another class file?</description>
		<content:encoded><![CDATA[<p>Ah, but what if every node had a map, and such a map would fire binding events. Further, what if each map&#8217;s elements were treated as a type of dynamic property? In this case, you would get the benefits of the second purpose without having to subclass, and without the cost of another class file?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stuart Marks</title>
		<link>http://fxexperience.com/2009/06/zhang-pacman-tutorial/comment-page-1/#comment-70</link>
		<dc:creator>Stuart Marks</dc:creator>
		<pubDate>Thu, 16 Jul 2009 04:51:30 +0000</pubDate>
		<guid isPermaLink="false">http://fxexperience.com/?p=71#comment-70</guid>
		<description>I think we need to consider carefully whether we really want have a rule that prohibits subclassing of the Shape classes.

There are (at least) two different purposes for subclassing. The first is to modify the behavior of the class, by overriding public methods/functions that the class uses to implement its own behavior. The second is to augment the class with application-specific information, so that there is a natural coupling between the application&#039;s data and the Shape (or whatever) that&#039;s being used to represent it on the screen.

It probably makes sense to prohibit subclassing for the first purpose but to allow the second. The reason the first purpose should be disallowed is that it creates dependencies between application code and the internal implementation of the superclass. This leads to breakage of the superclass&#039; behavior is modified. Subclassing for the second purpose is usually innocuous and can make application programming quite convenient.

I took a quick look through Henry Zhang&#039;s code, and it looks like he&#039;s mainly subclassing the Shape classes for the second purpose, to augment them with application-specific code and data. That seems OK to me.

It&#039;s overkill to declare that classes cannot be subclassed with something like the &#039;final&#039; modifier in Java, since this prohibits both uses of subclassing, when in fact only the first is dangerous.</description>
		<content:encoded><![CDATA[<p>I think we need to consider carefully whether we really want have a rule that prohibits subclassing of the Shape classes.</p>
<p>There are (at least) two different purposes for subclassing. The first is to modify the behavior of the class, by overriding public methods/functions that the class uses to implement its own behavior. The second is to augment the class with application-specific information, so that there is a natural coupling between the application&#8217;s data and the Shape (or whatever) that&#8217;s being used to represent it on the screen.</p>
<p>It probably makes sense to prohibit subclassing for the first purpose but to allow the second. The reason the first purpose should be disallowed is that it creates dependencies between application code and the internal implementation of the superclass. This leads to breakage of the superclass&#8217; behavior is modified. Subclassing for the second purpose is usually innocuous and can make application programming quite convenient.</p>
<p>I took a quick look through Henry Zhang&#8217;s code, and it looks like he&#8217;s mainly subclassing the Shape classes for the second purpose, to augment them with application-specific code and data. That seems OK to me.</p>
<p>It&#8217;s overkill to declare that classes cannot be subclassed with something like the &#8216;final&#8217; modifier in Java, since this prohibits both uses of subclassing, when in fact only the first is dangerous.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Stembridge</title>
		<link>http://fxexperience.com/2009/06/zhang-pacman-tutorial/comment-page-1/#comment-16</link>
		<dc:creator>Kevin Stembridge</dc:creator>
		<pubDate>Wed, 10 Jun 2009 08:45:18 +0000</pubDate>
		<guid isPermaLink="false">http://fxexperience.com/?p=71#comment-16</guid>
		<description>I think the &#039;final&#039; modifier in Java is a great way to make your code more robust and it would be nice to see it in JavaFX as well. I logged an issue a while back for making functions final. http://javafx-jira.kenai.com/browse/JFXC-2570. Add your vote if you agree.

That issue just refers to functions but I should have included classes as well.</description>
		<content:encoded><![CDATA[<p>I think the &#8216;final&#8217; modifier in Java is a great way to make your code more robust and it would be nice to see it in JavaFX as well. I logged an issue a while back for making functions final. <a href="http://javafx-jira.kenai.com/browse/JFXC-2570" rel="nofollow">http://javafx-jira.kenai.com/browse/JFXC-2570</a>. Add your vote if you agree.</p>
<p>That issue just refers to functions but I should have included classes as well.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven Bixby</title>
		<link>http://fxexperience.com/2009/06/zhang-pacman-tutorial/comment-page-1/#comment-15</link>
		<dc:creator>Steven Bixby</dc:creator>
		<pubDate>Wed, 10 Jun 2009 05:49:45 +0000</pubDate>
		<guid isPermaLink="false">http://fxexperience.com/?p=71#comment-15</guid>
		<description>Thanks for the point-out about subclassing Shape - but... why is that a bad thing?  Is there a technical reason, or just &quot;we might break it in the future&quot; reason?</description>
		<content:encoded><![CDATA[<p>Thanks for the point-out about subclassing Shape &#8211; but&#8230; why is that a bad thing?  Is there a technical reason, or just &#8220;we might break it in the future&#8221; reason?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
