Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add cloneable setting option #102

Merged
merged 2 commits into from
Jan 14, 2021
Merged

Add cloneable setting option #102

merged 2 commits into from
Jan 14, 2021

Conversation

timriley
Copy link
Member

This is an evolution from the approach in #100. With this change, settings may be specified with a cloneable option, e.g.

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

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

In the example above, 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 (see Setting#initialize_copy).

As the example here suggests, this change is in service of dry-system providing a new ”rich” component_dirs setting, providing an API like this:

# Inside a Dry::System::Container subclass
configure do |config|
  config.component_dirs.add("path/to/dir") do |dir|
    dir.auto_register = true
    dir.add_to_load_path = true
    # etc.
  end
end

This is closer to correct English, and mirrors similar concepts in other languages, like Java’s Cloneable interface
@timriley timriley changed the title Cloneable setting option Add cloneable setting option Jan 12, 2021
@timriley
Copy link
Member Author

FYI, I've tested this in dry-rb/dry-system#155 and it's working nicely there.

With this, the author of the configurable object can specify explicitly whether given setting values should be cloned.

This is useful when providing a custom default value with its own “rich” configuration interface, something different to the usual Array, Hash, and Set “primitives,” which were previously the only values that could be cloned.
@timriley timriley force-pushed the cloneable-setting-option branch from 115a406 to ae68141 Compare January 14, 2021 11:06
@timriley timriley merged commit 9d8e491 into master Jan 14, 2021
@timriley timriley deleted the cloneable-setting-option branch January 14, 2021 11:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants