Fix values, value? and key returning a superclass' overridden value

[dblock]

Fixes #62.

Bug

Several inheritance-aware methods had their own bespoke merge logic instead of using the memoized, deduping _enum_hash used by to_h, keys, key?, value, parse and each:

• values did a recursive list concatenation (superclass.values + result), so a subclass redefining a parent's key showed both the parent's stale value and its own override.
• value? and key relied on _enums_by_value, a hash merged by value rather than by key, so a superclass' stale value => enum mapping for an overridden key was never overwritten (it's a different hash key), leaving value?/key returning true/the key for values that no longer belong to that key.

class Colors
  include Ruby::Enum
  define :RED, 'red'
  define :GREEN, 'green'
end

class SubclassRedefiningParentKey < Colors
  define :RED, 'crimson'
end

SubclassRedefiningParentKey.values          # => ["red", "green", "crimson"] (bug: stale 'red')
SubclassRedefiningParentKey.value?('red')   # => true (bug: RED's value is now 'crimson')
SubclassRedefiningParentKey.key('red')      # => :RED (bug: stale mapping)

Fix

• values now reads from _enum_hash like every other method.
• _enums_by_value is now derived from _enum_hash (keyed by key) instead of merged directly by value, so overridden keys can't leave stale by-value entries behind.

SubclassRedefiningParentKey.values          # => ["crimson", "green"]
SubclassRedefiningParentKey.value?('red')   # => false
SubclassRedefiningParentKey.key('red')      # => nil

Updated/added specs covering both fixes.

Testing

• bundle exec rake (rubocop + rspec): 70 examples, 0 failures, rubocop clean (25 files)
• 100% line coverage maintained
• spec_i18n suite: 3 examples, 0 failures

[github-actions]

Danger Report

No issues found.

View run

[dblock]

@flvrone Take a look, this was YOLOed with Copilot but LGTM.

[flvrone]

@dblock Looks good! 👍