Talks
Speakers
Events
Topics
Search
Sign in
Search
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
search talks for
⏎
Suggest modification to this talk
Title
Description
RubyConf 2018 - Let's subclass Hash - what's the worst that could happen? by Michael Herold 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.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In his talk at RubyConf 2018, Michael Herold explores the complexities and pitfalls of subclassing core Ruby classes, specifically Hash. He introduces the topic with light humor and connects his experiences as a maintainer of the Hashie gem, which enhances hash functionalities but also brings to light some significant issues that arise from such practices. Key Points Discussed: - **Far-reaching Implications of Subclassing**: Michael emphasizes that subclassing core Ruby classes, like Hash, can lead to unexpected bugs and performance issues. He cites the proverb, "With great power comes great responsibility," asserting that developers often overlook the responsibilities tied to extending core classes. - **Indifferent Access Bug**: The first major bug Michael discusses involves the Indifferent Access feature in Hashie. This extension allows users to access hash keys with either strings or symbols. However, a bug was uncovered where the merge method did not behave as expected due to how the underlying Ruby classes interact, leading to a `no method error`. - **Mash Key Collisions**: Michael describes how Mash, another component of Hashie, can create conflicts with Ruby's built-in hash methods. For instance, accessing a key that collides with an enumerable method can produce perplexing outcomes, negatively impacting performance and causing confusion in user interactions with the data structure. - **Dash Data Structure**: He also discusses a third structure called Dash, which enforces specific properties within a hash. This structure complicates merging operations due to strict validations, illustrating how subclassing can unintentionally break expected behaviors within Ruby's classes. - **Public Method Rigor**: He points out that Ruby's Hash class contains around 178 public methods, introducing a vast interface that subclassing must contend with. This can lead to a higher likelihood of bugs and complexity in managing the interactions of overridden methods. Important Conclusions/Takeaways: - Michael cautions against the impulse to subclass core Ruby classes due to the hidden complications that may arise, emphasizing that alternative solutions, like OpenStruct, might offer simpler implementations without incurring the overhead that subclassing often entails. - He concludes with a strong recommendation to reconsider the necessity of tools like Hashie Mash in applications, advocating for direct parsing and manipulation of data to avoid potential pitfalls. The session wraps up with encouragement for audience members to reach out for further collaboration or contributions to Hashie, maintaining an open dialogue to foster better practices in Ruby development.
Suggest modifications
Cancel
