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