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

[WIP] use DefaultsKey.defaultValue for registering user defaults #189

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

DivineDominion
Copy link
Contributor

@DivineDominion DivineDominion commented Apr 16, 2019

I'm working on macOS apps and rely on the effect of register(defaults:) a lot. It didn't bother me to register them manually, using the swifty keys in the dictionary like so: DefaultsKeys.myKey._key : 123

But now that the keys require a default value, I'd like to not duplicate using this.

Either make the defaultValue public for compatibility, I figured, or offer a convenient wrapper around the register(defaults:) method. This is a prototype for the latter.

Is this a direction you want to go?

Usage:

extension DefaultsKeys {
    static let foo = DefaultsKey<Bool>("foo", defaultValue: true)
}

Defaults.register(defaultsKeys: [ DefaultsKeys.foo, ... ])

This works thanks to a protocol that type-erases the internals of DefaultsKey<T>:

public protocol DefaultsKeyable {
    var _key: String { get }
    var _defaultValue: Any? { get }
}

It's not that convenient to have to use DefaultsKeys.foo to reference the key. But I think the DefaultsKeys class can become a protocol instead, and the new DefaultsKeyable can inherit from that, and then it should work to write .register(defaultsKeys: [ .foo, ... ])

@sunshinejr
Copy link
Owner

@DivineDominion Yeah I agree, we should make defaultValue public - no reason to hide it behind our framework if it's user-provided value anyways. Would it make the implementation easier?

Also, about making DefaultsKeys a protocol - this would make it impossible to have stored values in extension, right? We would have to make them all computed?

@DivineDominion
Copy link
Contributor Author

Also, about making DefaultsKeys a protocol - this would make it impossible to have stored values in extension, right? We would have to make them all computed?

You're right, I totally missed that part.

@DivineDominion
Copy link
Contributor Author

During field-testing I found there's more work to be done:

  • defaultValue of a RawRepresentable enum is an enum case, but we want to get to defaultValue.rawValue in that case
  • similarly, custom types need to pass through the serialization bridge to be converted

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.

None yet

2 participants