Normalize == / eql? aliasing across value-like classes

[ericproulx]

Summary

Endpoint already followed the canonical Ruby pattern (def == then alias eql? ==), but several value-like classes either defined == without an eql? alias (so they wouldn't compare correctly as hash keys / set members), or defined the two as separate methods that drifted. Normalizing every one to the same shape:

def ==(other)
  ...
end
alias eql? ==

Equality changes

• Grape::Middleware::Stack::Middleware — add alias eql? ==.
• Grape::ServeStream::StreamResponse — same.
• Grape::ServeStream::FileBody — same.
• Grape::Util::MediaType — collapse the def ==(other); eql?(other); end trampoline + separate def eql? into a single == body with alias eql? ==. Same behaviour, one fewer dispatch.
• Grape::Exceptions::ErrorResponse — same collapse.
• Grape::Namespace — flip from def eql? ... alias == eql? to def == ... alias eql? == so the codebase is consistent on one direction.
• Grape::Util::InheritableSetting — add def ==(other) (compares via to_hash internally) and alias eql? ==. The class previously had no equality at all, so Endpoint#== had to call inheritable_setting.to_hash == other.inheritable_setting.to_hash to compare. With this in place:
• Grape::Endpoint#== simplifies from inheritable_setting.to_hash == other.inheritable_setting.to_hash to plain inheritable_setting == other.inheritable_setting.

Grape::Endpoint's own == was already canonical and remains so.

Encapsulation cleanup in InheritableSetting

While in the file, tightened the public surface — none of route, api_class, namespace, namespace_inheritable, namespace_stackable, namespace_reverse_stackable, parent, point_in_time_copies is written from outside the class anywhere in lib/ or spec/. They were attr_accessor but only ever needed attr_reader.

• Switched attr_accessor → attr_reader for all eight.
• initialize and inherit_from now write to @ivar directly instead of the awkward self.foo = … setter syntax (matching route_end's existing @route = {}).
• point_in_time_copy previously mutated the new instance by calling its public setters from the outside. Replaced that with a single protected copy_state_from(source) helper on InheritableSetting itself — the new instance pulls its state from source from inside the class, with no public writers required.

Why it matters

Without the alias, [obj1].include?(obj2) and Set#include? use eql? (which falls back to equal? / object identity) instead of the custom ==, producing surprising false results when two value-equal instances are compared by hash-based collections. The InheritableSetting encapsulation cleanup is a related-but-separate readability win — the class no longer leaks writable state, and internal mutations go through the canonical @ivar = … form.

Test plan

• bundle exec rspec — 2292 examples, 0 failures
• RuboCop clean on touched files
• CI green across Gemfile variants

🤖 Generated with Claude Code

[github-actions]

Danger Report

No issues found.

View run