v0.12.1

Added

• Settings may be specified with a cloneable option, e.g.

setting :component_dirs, Configuration::ComponentDirs.new, cloneable: true

This change makes it possible to provide “rich” config values that carry their own
configuration interface.

In the above example, ComponentDirs could provide its own API for adding component
dirs and configuring aspects of their behavior at the same time. By being passed to
the setting along with cloneable: true, dry-configurable will ensure the setting's
values are cloned along with the setting at all the appropriate times.

A custom cloneable setting value should provide its own #initialize_copy (used by
Object#dup) with the appropriate logic. (@timriley in #102)

Fixed

• Only #initialize instance method is prepended, leaving the rest of the instance
  methods to be included as normal again. This allows classes including
  Dry::Configurable to override instance methods with their own methods as required
  (@adam12 in #103)

Compare v0.12.0...v0.12.1

v0.12.0

0.12.0 2020-12-26

Fixed

• Setting values provided by defaults and/or pre-processor blocks are no longer accidentally memoized across instances of classes including Dry::Configurable (#99) (@timriley & @esparta)

Changed

• Instance behavior is now prepended, so that if you have your own initialize, calling super is no longer required (see #98 for more details) (@zabolotnov87)
• Switched to equalizer from dry-core (@solnic)

Compare v0.11.6...v0.12.0

v0.11.6

Changed

• A meaningful error is raised when the extension is included more than once (issue #89 fixed via #94) (@landongrindheim)
• Evaluate setting input immediately when input is provided. This allows for earlier feedback from constructors designed to raise errors on invalid input (#95) (@timriley)

Compare v0.11.5...v0.11.6

v0.11.5

Fixed

• When settings are copied or cloned, unevaluated values will no longer be copied. This prevents unintended crashes when settings have constructors expecting a certain type of value, but that value is yet to be provided (Fixed via #87) (@timriley)

Compare v0.11.4...v0.11.5

v0.11.4

Fixed

• Config#update returns self again (issue #60 fixed via #92) (@solnic)

Changed

• Setting#inspect no longer uses its value - this could cause crashes when inspecting settings that are yet to have a value applied (e.g. when they have a constructor that expects a value to be present) (@timriley)

Compare v0.11.3...v0.11.4

v0.11.3

Fixed

• Retrieving settings by a string name works again (issue #82) (@waiting-for-dev)

Compare v0.11.2...v0.11.3

v0.11.2

Fixed

• Warning about redefined Setting#value is gone (@solnic)

Compare v0.11.1...v0.11.2

v0.11.1

Fixed

• You can use :settings as a config key again (issue #80) (@solnic)
• Setting value is lazy-evaluated now, which fixes some cases where a constructor could crash with a nil value (@solnic)

Compare v0.11.0...v0.11.1

v0.11.0

A complete rewrite of the library while keeping the public API intact. See #78 for a detailed overview.

Changed

• Accessing config in a parent class no longer prevents you from adding more settings in a child class (@solnic)
• (internal) New low-level Setting and Config API (@solnic)
• (internal) config objects use method_missing now (@solnic)

v0.9.0

0.9.0 - 2019-11-06

Fixed

• Support for reserved names in settings. Some Kernel methods (public_send and class specifically) are not available if you use access settings via a method call. Same for methods of the Config class. You can still access them with [] and []=. Ruby keywords are fully supported. Invalid names containing special symbols (including ! and ?) are rejected. Note that these changes don't affect the reader option, if you define a setting named :class and pass reader: true ... well ... (flash-gordon)
• Settings can be redefined in subclasses without warnings about overriding existing methods (flash-gordon)
• Fix warnings about using keyword arguments in 2.7 (koic)

Compare v0.8.3...0.9.0