Inherit keys, key?, value?, key, value, to_h, parse and each from superclass

[dblock]

Summary

Follow-up to #49 / #58.

values already merges enums from a class' entire superclass chain, but keys, key?, value?, key, value, to_h, parse and each only looked at a class' own enums, silently ignoring anything defined in a superclass:

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

class FirstSubclass < Colors
  define :ORANGE, 'orange'
end

FirstSubclass.values  # => ["red", "green", "orange"]  (correct, already worked)
FirstSubclass.keys    # => [:ORANGE]                   (missing :RED, :GREEN!)
FirstSubclass.key?(:RED) # => false                    (wrong)

Fix

Introduces _enum_hash/_enums_by_value private methods that merge a class' own enums with those of its superclass chain (a subclass' own definitions take precedence over an identically-named key/value defined in a superclass). All read methods (keys, key?, value?, key, value, to_h, parse, each, each_key, each_value) now use these merged views, consistent with values.

define's duplicate-key/duplicate-value validation still only looks at the class' own enums (via new _own_enum_hash/_own_enums_by_value), preserving the existing (and tested) ability for a subclass to redefine a key or value already used by a superclass.

Testing

• Added specs for FirstSubclass (which defines its own enums) and SubclassWithNoOwnDefines (from Fix NoMethodError on enum methods when subclass defines no enums of its own #58) covering keys, key?, value?, key, value, to_h, parse, and each.
• bundle exec rspec spec/ - 63 examples, 0 failures, 100% line coverage.
• bundle exec rubocop - clean.
• spec_i18n suite - 3 examples, 0 failures.

[github-actions]

Danger Report

No issues found.

View run