<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Sustainable Development in Ruby, Part 2: Method Injection</title>
	<link>http://avdi.org/devblog/2008/03/31/sustainable-development-in-ruby-part-2-method-injection/</link>
	<description></description>
	<pubDate>Sat, 19 Jul 2008 20:18:39 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: Virtuous Code &#8250; Sustainable Development in Ruby Part 3: Delegation</title>
		<link>http://avdi.org/devblog/2008/03/31/sustainable-development-in-ruby-part-2-method-injection/#comment-56</link>
		<dc:creator>Virtuous Code &#8250; Sustainable Development in Ruby Part 3: Delegation</dc:creator>
		<pubDate>Thu, 17 Apr 2008 20:46:31 +0000</pubDate>
		<guid>http://avdi.org/devblog/2008/03/31/sustainable-development-in-ruby-part-2-method-injection/#comment-56</guid>
		<description>[...] our last episode we were augmenting FMTP::Message classes to deal with messages split across multiple packets. As is [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] our last episode we were augmenting FMTP::Message classes to deal with messages split across multiple packets. As is [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: avdi</title>
		<link>http://avdi.org/devblog/2008/03/31/sustainable-development-in-ruby-part-2-method-injection/#comment-55</link>
		<dc:creator>avdi</dc:creator>
		<pubDate>Thu, 17 Apr 2008 16:16:42 +0000</pubDate>
		<guid>http://avdi.org/devblog/2008/03/31/sustainable-development-in-ruby-part-2-method-injection/#comment-55</guid>
		<description>Shalev:

1. To quote Knuth, premature optimization is the root of all evil ;-)  Considering that our mythical Flying Monkey Transport Protocol probably has a packet latency measured in hours, I suspect that this is the least of their performance problems.

2. See the introduction to this series.  If two separate pieces of code independently try to add the same method, it's no longer a method addition and becomes an inadvertent method redefinition.

3a. I apply &lt;a href="http://c2.com/xp/YouArentGonnaNeedIt.html" rel="nofollow"&gt;YAGNI&lt;/a&gt; pretty religiously.  I used to code based on the "we'll need it someday" principle a long time ago, and it never got me anywhere good.

3b. Reuse is not the only reason to extract code into a method.  Other reasons include readability and enforcing the Single Responsibility Principle.  The code that calls #end? is not concerned with how we know that the message is at the end, but with what to do if it is.  Having the implementation details of &lt;em&gt;how&lt;/em&gt; we know at that point is a distraction from the core purpose of the code.

But this kind of misses the point anyway, because this is demo code which I have deliberately kept simple in order to focus on the techniques being presented.  In the real world #end? might very well be a more complicated (and distracting) algorithm.</description>
		<content:encoded><![CDATA[<p>Shalev:</p>
<p>1. To quote Knuth, premature optimization is the root of all evil <img src='http://avdi.org/devblog/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />  Considering that our mythical Flying Monkey Transport Protocol probably has a packet latency measured in hours, I suspect that this is the least of their performance problems.</p>
<p>2. See the introduction to this series.  If two separate pieces of code independently try to add the same method, it&#8217;s no longer a method addition and becomes an inadvertent method redefinition.</p>
<p>3a. I apply <a href="http://c2.com/xp/YouArentGonnaNeedIt.html" rel="nofollow">YAGNI</a> pretty religiously.  I used to code based on the &#8220;we&#8217;ll need it someday&#8221; principle a long time ago, and it never got me anywhere good.</p>
<p>3b. Reuse is not the only reason to extract code into a method.  Other reasons include readability and enforcing the Single Responsibility Principle.  The code that calls #end? is not concerned with how we know that the message is at the end, but with what to do if it is.  Having the implementation details of <em>how</em> we know at that point is a distraction from the core purpose of the code.</p>
<p>But this kind of misses the point anyway, because this is demo code which I have deliberately kept simple in order to focus on the techniques being presented.  In the real world #end? might very well be a more complicated (and distracting) algorithm.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shalev</title>
		<link>http://avdi.org/devblog/2008/03/31/sustainable-development-in-ruby-part-2-method-injection/#comment-52</link>
		<dc:creator>Shalev</dc:creator>
		<pubDate>Tue, 15 Apr 2008 06:27:24 +0000</pubDate>
		<guid>http://avdi.org/devblog/2008/03/31/sustainable-development-in-ruby-part-2-method-injection/#comment-52</guid>
		<description>A few points:

1. This strikes me as fairly inefficient.  Assuming this receive loop works for a while, you've just created a large number of objects and then dynamically defined a method on each one.

2. You state that "adding an undefined method...is not without its risks," but you fail to state what those risks are.

3. "we only need the #end? method in one place"  This may be true now, but surely the method may be useful further down the line.  What's more, if this really is true, I don't see your logic for creating a special #end? method anyway.  message.data.include?("ENDENDEND") isn't a large statement and it has the added advantages of being clearer and more specific (without requiring someone reading your code to jump down to the #end? method to see what the end condition is.)  Normally you would move code into a method in order to reuse it.  If you're not going to do that, then there really isn't much of a point to creating a separate method.</description>
		<content:encoded><![CDATA[<p>A few points:</p>
<p>1. This strikes me as fairly inefficient.  Assuming this receive loop works for a while, you&#8217;ve just created a large number of objects and then dynamically defined a method on each one.</p>
<p>2. You state that &#8220;adding an undefined method&#8230;is not without its risks,&#8221; but you fail to state what those risks are.</p>
<p>3. &#8220;we only need the #end? method in one place&#8221;  This may be true now, but surely the method may be useful further down the line.  What&#8217;s more, if this really is true, I don&#8217;t see your logic for creating a special #end? method anyway.  message.data.include?(&#8220;ENDENDEND&#8221;) isn&#8217;t a large statement and it has the added advantages of being clearer and more specific (without requiring someone reading your code to jump down to the #end? method to see what the end condition is.)  Normally you would move code into a method in order to reuse it.  If you&#8217;re not going to do that, then there really isn&#8217;t much of a point to creating a separate method.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: This Week in Ruby (April 7, 2008) &#124; Zen and the Art of Programming</title>
		<link>http://avdi.org/devblog/2008/03/31/sustainable-development-in-ruby-part-2-method-injection/#comment-40</link>
		<dc:creator>This Week in Ruby (April 7, 2008) &#124; Zen and the Art of Programming</dc:creator>
		<pubDate>Mon, 07 Apr 2008 10:07:40 +0000</pubDate>
		<guid>http://avdi.org/devblog/2008/03/31/sustainable-development-in-ruby-part-2-method-injection/#comment-40</guid>
		<description>[...] Sustainable Development in Ruby (part 1 and part 2) [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Sustainable Development in Ruby (part 1 and part 2) [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
