<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for Me</title><link>http://disqus.com/people/4dea430d31b993abaf41cd9b54f8128d/</link><description></description><language>en</language><lastBuildDate>Mon, 14 Jul 2008 17:43:28 -0000</lastBuildDate><item><title>Re: First Post!</title><link>http://virtuouscode.disqus.com/first_post/#comment-1471650</link><description>test</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Me</dc:creator><pubDate>Sun, 02 Dec 2007 21:13:54 -0000</pubDate></item><item><title>Re: Monkeypatching is Destroying Ruby</title><link>http://virtuouscode.disqus.com/monkeypatching_is_destroying_ruby/#comment-1471662</link><description>@andrew:&lt;br&gt;&lt;br&gt;&amp;gt; You do monkey-patch in your NullDB. You reopen AR::Base to add a nulldb_connection method.&lt;br&gt;&lt;br&gt;True.  This, unfortunately, is part of the contract of the&lt;br&gt;ActiveRecord connection adapter API - you are expected to do this if&lt;br&gt;you want connection_establish :adapter =&amp;gt; :foo to work.  Whether this&lt;br&gt;is a true "monkey patch" is debatable; a lot of people only consider&lt;br&gt;such a thing a monkey patch if it actually *redefines* existing&lt;br&gt;methods.  Of course, the Rails guys could easily have avoided the&lt;br&gt;whole question by giving us a less-silly API that allowed us to simply&lt;br&gt;register a new database connection class.&lt;br&gt;&lt;br&gt;&amp;gt; Subclassing isn't always possible. With AR::Base subclasses have special&lt;br&gt;&amp;gt; semantic meaning, ie. Single Table Inheritance. That is why everything with&lt;br&gt;&amp;gt; ActiveRecord is done through mix-ins +/or eval. (You can subclass AR::Base&lt;br&gt;&amp;gt; not for STI but it's a pain)&lt;br&gt;&lt;br&gt;It's not a pain, you just set abstract_class = true.&lt;br&gt;&lt;br&gt;&amp;gt; Whether it is the Rails framework or a plugin, understand it enough to debug&lt;br&gt;&amp;gt; it. Then you can eval as much as you like.&lt;br&gt;&lt;br&gt;This is easy to say, but in real world large projects it simply isn't&lt;br&gt;feasible to understand all of the code in the project, let alone all&lt;br&gt;of the third-party code it depends on.  That is why community&lt;br&gt;conventions are essential for maintainability.&lt;br&gt;&lt;br&gt;Thanks for the comment!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Me</dc:creator><pubDate>Thu, 28 Feb 2008 12:24:09 -0000</pubDate></item><item><title>Re: Sustainable Development in Ruby, Part 1: Good Old-Fashioned Inheritance</title><link>http://virtuouscode.disqus.com/sustainable_development_in_ruby_part_1_good_old_fashioned_inheritance/#comment-1471689</link><description>Pat: I understand your point, but this was the inheritance post :-)  Composition will come later.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Me</dc:creator><pubDate>Sat, 29 Mar 2008 17:37:26 -0000</pubDate></item><item><title>Re: Announcing Ninja-Patching!</title><link>http://virtuouscode.disqus.com/announcing_ninja_patching/#comment-1471704</link><description>Paul:  sorry about the lost comment.  I'm increasingly not a fan of WordPress, period.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Me</dc:creator><pubDate>Tue, 01 Apr 2008 21:05:20 -0000</pubDate></item><item><title>Re: Why Your Social Website Should Support OpenID</title><link>http://virtuouscode.disqus.com/why_your_social_website_should_support_openid/#comment-1471707</link><description>Giles, I'm a user.  I'm speaking as a user, and nothing else.  OpenID is of genuine value to me as a user.  It is convenient and makes my life easier.  Perhaps every other user in the world maps to your model and finds no use at all in it.  But for me it has real utility.  Chris was looking for how it was useful, and so (I thought) were you, and now I've explained it.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Me</dc:creator><pubDate>Sat, 12 Apr 2008 20:33:53 -0000</pubDate></item><item><title>Re: Phenomenal Cosmic Power</title><link>http://virtuouscode.disqus.com/phenomenal_cosmic_power/#comment-1471727</link><description>JMAGS: Thanks!  I don't know what I was thinking.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Me</dc:creator><pubDate>Mon, 14 Jul 2008 17:43:28 -0000</pubDate></item><item><title>Re: alias_method_chain :alias_method_chain, :awesome (or, how I learned to stop worrying and made Python nation and anyone else afraid of monkey-patching my bitch)</title><link>http://patmaddox.disqus.com/alias_method_chain_alias_method_chain_awesome_or_how_i_learned_to_stop_worrying_and_made_python_nati/#comment-5764723</link><description>Not bad, just needlessly overused. I hope you read the whole article, not just the title. The followups ([first](http://avdi.org/devblog/2008/02/25/followup-to-monkeypatching-is-destroying-ruby/), [second](http://avdi.org/devblog/2008/02/25/full-disclosure/)) hopefully clarify some more.&lt;br&gt;&lt;br&gt;I actually think *alias_method_chain* is slightly less dangerous than some other techniques, because at least it's a convention and a way to avoid silently stomping existing methods. But that's a good technique for the environments where *alias_method_chain* is available, and I may utilize it next time I'm debugging unexpected behavior in Rails. Thanks!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Me</dc:creator><pubDate>Wed, 27 Feb 2008 12:16:00 -0000</pubDate></item></channel></rss>