Have you ever been tempted to subclass a core class like Hash or String? Or have you read blog posts about why you shouldn’t do that, but been left confused as to the specifics? As a maintainer of Hashie, a gem that commits this exact sin, I’m here to tell you why you want to reach for other tools instead of the subclass.

In this talk, you’ll hear stories from the trenches about what can go wrong when you subclass core classes. We’ll dig into Ruby internals and you will leave with a few new tools for tracking down seemingly inexplicable performance issues and bugs in your applications.

References

• “Hashie Considered Harmful” by Richard Schneeman
• “YAGNI methods are killing me” by Aaron Patterson
• “Provide sharp knives” by David Heinemeier Hansson

Extras

To reproduce the table at the end of the talk about top-downloaded gems that use Hashie, you can download a RubyGems.org data backup and follow their example script to import it into your local database. The following query is what I used to calculate download rank:

WITH latest_versions AS (

    SELECT versions.rubygem_id,
           MAX(versions.id) AS id
      FROM versions
    GROUP BY versions.rubygem_id

),

dependers AS (

  SELECT DISTINCT dependencies.version_id
    FROM dependencies
         INNER JOIN rubygems ON dependencies.rubygem_id = rubygems.id
   WHERE rubygems.name = 'hashie'

),

dependent_latest_versions_of_gems AS (

  SELECT latest_versions.rubygem_id
    FROM dependers
         INNER JOIN latest_versions ON latest_versions.id = dependers.version_id

)

  SELECT DISTINCT rubygems.id,
         rubygems.name
    FROM dependent_latest_versions_of_gems
         INNER JOIN rubygems ON rubygems.id = dependent_latest_versions_of_gems.rubygem_id
ORDER BY rubygems.name ASC