RubyConf 2018: Let's Subclass Hash - What's the Worst That Could Happen?

  • less than one minute

The RubyConf 2018 logo.

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.


https://www.youtube.com/watch?v=KzdSxgVPhXU

References

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