mikeash.com pyblog/friday-qa-2017-10-06-type-safe-user-defaults.html comments

rjt - 2017-10-07 21:32:19

Sat, 07 Oct 2017 21:32:19 GMT

@Macmade That's a beautifully elegant piece of code!

Macmade - 2017-10-06 17:34:46

Fri, 06 Oct 2017 17:34:46 GMT

Interesting implementation.
I usually use reflection in order to achieve this.

Using the Objective-C runtime, or a Mirror in Swift.

The goal is to declare usual properties, and let the reflection initialise and update them.

Writing to NSUserDefaults is then done with KVO, for each reflected property, so everything is automatic, you just have to declare the properties.

As an example: https://gist.github.com/macmade/0824d91b1f3a3b095057a40742d50a03

Maxim - 2017-10-06 16:59:25

Fri, 06 Oct 2017 16:59:25 GMT

I’ve been using SwiftyUserDefaults for a while:
https://github.com/radex/SwiftyUserDefaults

Key differences:
- you have to declare both var name and key name (#2 in your wishlist)
- you can’t provide default value (#6). I made a pull request for that, but it’s ignored
https://github.com/radex/SwiftyUserDefaults/pull/95
- I think it makes more semantic sense to subscript Defaults to get a value, instead of getting it from a key.value property. It’s clear that you get it from Defaults.

mikeash - 2017-10-06 15:27:53

Fri, 06 Oct 2017 15:27:53 GMT

Good call. I tried it with Optional<Any> and that failed, but Optional<Codable> appears to work.

Jean-Daniel - 2017-10-06 14:17:07

Fri, 06 Oct 2017 14:17:07 GMT

Instead of handling all types, what about handling only the Codable case ?

case let value as Optional<Codable> where value == nil: return nil

Gwynne Raskind - 2017-10-06 13:52:11

Fri, 06 Oct 2017 13:52:11 GMT

Ooo, good point. I wonder if that's a limitation of Swift generics or just an algorithmic thing. Feels like the ability to do something similar to C++'s specializations would solve it.

mikeash - 2017-10-06 13:41:39

Fri, 06 Oct 2017 13:41:39 GMT

Man, you really can tell when I just write code directly in the article and don't compile it. Fixed, thanks.

Your proposal for nil checking doesn't work because you can't use the bare Optional type. You have to specialize it. So you can do as Optional<Int> or as Optional<String> but you'd have to write out every type you wanted to handle.

Gwynne Raskind - 2017-10-06 13:35:58

Fri, 06 Oct 2017 13:35:58 GMT

In let otherDefaults = UserDefaults(suitName: "...")! shouldn't that be suiteName?

Re: Optionals, why did you need the isNil property versus treating it as an enum with something like case let value as Optional where .none (except, you know, correct syntax that I don't remember because pattern matching syntax in Swift is weird)?