Open DivineDominion opened 5 years ago
@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?
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.
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
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 theregister(defaults:)
method. This is a prototype for the latter.Is this a direction you want to go?
Usage:
This works thanks to a protocol that type-erases the internals of
DefaultsKey<T>
:It's not that convenient to have to use
DefaultsKeys.foo
to reference the key. But I think theDefaultsKeys
class can become a protocol instead, and the newDefaultsKeyable
can inherit from that, and then it should work to write.register(defaultsKeys: [ .foo, ... ])