#keypath

키패스는 어떤 객체의 프로퍼티 혹은 프로퍼티의 프로퍼티 체인에 대해서 그 이름을 통해서 값을 찾아나가는 표현을 말한다. Objective-C에서 키패스는 키패스 경로를 나타내는 문자열을 사용해서 특정 객체의 속성을 액세스하기 때문에 컴파일 타임이 아닌 런타임에 액세스해야 할 프로퍼티를 결정하는 동적 기능으로 키밸류코딩과 키밸류 옵저빙에 사용된다. Swift2까지는 Swift 내에 키패스에 대한 기능이 별도로 마련되지 않았고, NSObject의 value(forKey:)나 setValue(_:forKey:)를 사용하면서 문자열을 그대로 사용했다.

문자열을 통해서 키패스를 사용하는 것은 편리할 수는 있으나, 컴파일 타임에서 오타에 의해 존재하지 않는 키패스를 참조하는 것을 체크할 방법이 없어서 디버깅이…

original source : https://medium.com/the-traveled-ios-developers-guide/swift-3-keypath-7a3cf41e603e

my review point 6/10

참고사항) https://stackoverflow.com/a/47362420/3151712

According to the docs:

In Objective-C, a key is a string that identifies a specific property of an object. A key path is a string of dot-separated keys that specifies a sequence of object properties to traverse.

Significantly, the discussion of #keyPath is found in a section titled "Interacting with Objective-C APIs". KVO and KVC are Objective-C features.

All the examples in the docs show Swift classes which inherit from NSObject.

Finally, when you type #keyPath in Xcode, the autocomplete tells you it is expecting an @objc property sequence.

Expressions entered using #keyPath will be checked by the compiler (good!), but this doesn't remove the dependency on Objective-C.

I love video games. That may not come as a surprise, given that I am a programmer by trade. And for years I’ve been plagued by one tiny problem in the domain. The current Xbox One’s power button is so easy to accidentally tap and cut your precious gaming session short. It’s flat, hidden and not very practical. So, during E3 2016 — when Microsoft proudly displayed the next Xbox, it was telling that I was most taken with one tiny detail.

A tactile power button. A small, incremental, and applicable improvement that just makes thing so much better.

So today — we’ll talk about the Swift 3 equivalent of that — #keyPath().

The Typo — No Longer

Let’s agree on two simple truths in iOS programming. One will inevitably make a typo, and one will also use K.V.O somewhere down the beaten path. The former is true regardless of your programming language of choice.

But, since the API is driven (mostly) off of a fragile string literal — things go wrong far too easily:

let aController = UIViewController()

aController.addObserver(self, forKeyPath: “OH_GEEZ_HOPE_DIS_RIGHT”, options:[], context: nil)

True, some of this is mitigated by global variables, constants and enumerations. It’s a shame, though — since Foundation, UIKit and everything else in between makes clever use of the tech. This is like giving your freshly minted 16 year old son a Bugatti Chiron for his first vehicle.

And, being able to observe changes for any key-path on an ad-hoc basis can yield flexibility and promote abstraction, but the truth remains that it’s far too easy to scrub. Swift 3 smashes this problem to absolute oblivion by enforcing compile time checks on such key-paths.

let aController = UIViewController()

aController.addObserver(self, forKeyPath: #keyPath("anObject.someProperty"), options:[], context: nil)

In Practice

Using #keyPath(), a static type check will be performed by virtue of the key-path literal string being used as a StaticString or StringLiteralConvertible. At this point, it’s then checked to ensure that it A) is actually a thing that exists and B) is properly exposed to Objective-C.

So, with our first code sample, clang would kindly tell us that “OH_GEEZ_HOPE_DIS_RIGHT” doesn’t exist in the current context. Before, this was assuredly Objective-C Roulette, as the alternative was finding out the key-path was bogus by the way of a runtime exception. No longer:

let aController = UIViewController()

//This line produces a compile time warning since it's now //A compiler checked expression aController.addObserver(self, forKeyPath: #keyPath(“OH_GEEZ_HOPE_DIS_RIGHT”), options:[], context: nil)

Level with me and think about just how easy it is to get this wrong:

class Foo {    let aProp:String = “A Value” }

let anObject = NSObject()

anObject.addObserver(anObject, forKeyPath: “Foo.aPop”, options: [], context: nil)

Unless one reads with extra intent, it’s easy for the eyes to scan right past the error in the previous code, “Foo.aPop”, which is not a valid key-path. Using the #keyPath() expression, we wouldn’t even compile — which is exactly what we’d want to happen.

By ensuring matches to valid key-paths — even the common refactor is no longer a dangerous proposition:

class Foo {    let aRenamedProp:String = “A Value” }

let anObject = NSObject()

//Compile time error is produced since #keyPath() contains the //Old property name anObject.addObserver(anObject, forKeyPath: #keyPath(“Foo.aProp”), options: [], context: nil)

Better yet — #keyPath() packs in autocompletion as well, so it’s even less likely for one to author such code to begin with. Bravo.

I know this piece is lighter on content than most entries, but that’s telling in of itself. I love this feature, and it’s elementary to explain — a hallmark of beautiful refactoring in the world or programming. There really isn’t much to say, other than it’s great and certainly a delightful enhancement.

Be sure to say hi to #keyPath()’s close cousin while you’re in town too, #selector().

Final Thoughts

Listen, I think #keyPath() is my spirit animal.

I’ve spent an embarrassing amount of time chasing down a bug that was produced by a misspelled string. KVO and KVC were always great tools for any iOS developer to wield, but now one can utilize such techniques with a greater peace of mind that only clang can bring.

To me, this Swift 3 tweak is just begging to yield war stories to the next generation of Swift developers. I can see us all now, “Back in my day, you had to just type a key-path and hope it was right! None of this sticky, compile time checking. That’s right, we were so alive back then! And — we didn’t even have ABI compatibility!”

original source : https://www.klundberg.com/blog/swift-4-keypaths-and-you/

my review points 7/10

Swift 4 is almost upon us, and I thought I would explore one of its features that I haven’t had the opportunity to that much: KeyPaths. There’s a lot of interesting nuance in here that I previously didn’t realize existed which I’d love to share.

In short, KeyPaths are a type-safe way to separate referencing a type’s property from evaluating that property and getting a result back. You can already do that today in Swift 3 with functions, but until Swift 4 is released you can’t do so with properties without wrapping them in a closure, or with using the old unsafe #keyPath() syntax if your code is running on ios/mac/etc:

struct Person {  let name: String  func greet() {    print("Hello \(name)!")  } } let p = Person(name: "Samus") let greeter = p.greet // stores the method without evaluating it. greeter() // calls the stored method // this is the only way in Swift 3.1 and below to defer evaluating the name property of a Person. let getName = { (p: Person) in p.name } print(getName(p)) // evaluate the property

With Swift 4 you can rewrite the last two lines above like so:

let getName = \Person.name print(p[keyPath: getName]) // or just this: print(p[keyPath: \Person.name])

\Person.name is the way to construct a KeyPath<Person, String> where the first generic parameter is the root type (what type we are querying), and the second generic parameter is the type of the value we are asking for. Using this, we can ask for the value of the name property from any instance of Person, but without the overhead of defining a closure every time we might want to ask for it. You can query more than one level as well. If you wanted to get a KeyPath for the length of a person’s name, you could write \Person.name.count.

In this example we created a KeyPath which is read-only, because the nameproperty on Person was defined as a let. What happens if we change it to a var?

struct Person {  var name: String  func greet() {    print("Hello \(name)!")  } } let kp = \Person.name var p = Person(name: "Samus") p[keyPath: kp] = "Ridley" p.greet() // prints "Hello Ridley!"

In this case, since name is defined as a var, \Person.name is a WritableKeyPath<Person, String> which means we can use the subscript to set values in addition to getting them. If we tried to use the subscript setter for a let property we’d actually get a compiler error since settable subscripts are not defined for the plain KeyPath type, only WritableKeyPathwhich is a pretty nice way to make sure you can’t do something that isn’t possible.

There are more KeyPath types than just KeyPath and WritableKeyPath as well. If you look at the Swift Evolution proposal for KeyPaths or the generated interface for the KeyPath classes in Xcode, you’ll see that the KeyPath types are actually a 5-deep linear class hierarchy:

AnyKeyPath    |    v PartialKeyPath<Root>    |    v KeyPath<Root, Value>    |    v WritableKeyPath<Root, Value>    |    v ReferenceWritableKeyPath<Root, Value>

We went over the third and fourth type which are pretty easy to grok, but the others may not be. ReferenceWritableKeyPath is a subclass of WritableKeyPath which means that it can also be used both in a KeyPath getter and setter, but that’s the type of KeyPath you get if you referenced a mutable property on a class:

class BankAccount {  var balance: Decimal = 0  var owner: Person } // Creates a ReferenceWritableKeyPath<BankAccount, Decimal>: let kp = \BankAccount.balance

ReferenceWritableKeyPath is necessary so that the compiler can know whether it’s safe to allow you to use a KeyPath setter on a value that’s stored in a constant. If that value is a class type, then mutating the value’s properties is possible in any context, therefore this KeyPath is the only one that can be used for it. If it was a struct or other value type stored in a constant, you would not be able to set something with the keyPath:subscript since that would change the value itself, which is not allowed for let constants.

Moving up the tree we have PartialKeyPath<Root>. This KeyPath has a concrete root, but an unknown value type at compile time. It could be useful in cases where you might want to store all of a type’s KeyPaths in a generic data structure or if you want to do other things that don’t rely on a KeyPath’s evaluated value, since the resulting value is returned as the Any type:

이코드에 오타가 있는 것 같아 수정

let kp: PartialKeyPath<Person>: \Person.name

let kp: PartialKeyPath<Person>= \Person.name

이코드에 아래 내용이 없으므로 추가 해야 할듯

let person = Person();

struct Person {  var name: String  let birthdate: Date } let kp: PartialKeyPath<Person>: \Person.name type(of: person[keyPath: kp]) // returns Any let personPaths: [PartialKeyPath<Person>] = [    \Person.name,    \Person.birthdate, ] // only possible with PartialKeyPath since name and birthdate are different types

Finally there’s the base class for everything, AnyKeyPath. Here we don’t know the type of the value OR the type of the root at compile time. These can be queried at runtime though if necessary:

let kp: AnyKeyPath = \Person.birthdate kp.rootType // evaluates to Person.self kp.valueType // evaluates to Date.self

These properties are available to all the subclasses as well, though they’re not very interesting once you get to KeyPath since you already have the compile time generic type parameters at that point.

Combining KeyPaths

There’s another cool thing you can do with KeyPaths: combining them together! Every KeyPath type has a number of appending methods that let you stick together two KeyPaths to make one mega-KeyPath:

let accountOwnerPath = \BankAccount.owner let namePath = \Person.name let accountOwnerNamePath = accountOwnerPath.appending(namePath) // returns KeyPath<BankAccount, String> let account: BankAccount = ... account[keyPath: accountOwnerNamePath] // returns the name of the account owner

You can only append two KeyPaths if the Value of the first one in the chain is of the same type as the Root of the second one in the chain. If you try to append two wholly-unrelated KeyPaths, you’ll get different behavior depending on which type of KeyPath you’re working with. If you’re working with KeyPath and its subclasses exclusively, the compiler can check your work and give you a compiler error if the types don’t match up nicely. However if you’re working with AnyKeyPath or PartialKeyPath, appending those together with any KeyPath type will result in returning an optional KeyPath, where you’ll get nil at runtime if the KeyPaths’ types don’t line up properly.

Combining KeyPaths has some other interesting behavior around how the types of the KeyPaths you combine affect the KeyPath you get back. For instance, appending a KeyPath and a WritableKeyPath gives you a read-only KeyPath since it’s not possible to mutate a property in the normal case either:

struct Person {  let birthPlanet: Planet } struct Planet {  var name: String } var person: Person = ... person.birthPlanet.name = "SR388" // error: can't mutate birthPlanet.name person[keyPath: \Person.birthPlanet.name] = "Zebes" // error for the same reason

When working with ReferenceWritableKeyPath though, it doesn’t always take the least strict version. If you append a ReferenceWritableKeyPath to the end of anything else (except AnyKeyPath), the result is a ReferenceWritableKeyPath since the KeyPath can safely mutate anything at the end of the chain if there’s reference semantics somewhere along the way. If you append a read-only KeyPath to the end of a ReferenceWritableKeyPath though, it’s still just a KeyPath since the tail end of the chain is still immutable.

The full table of ways you can combine KeyPaths and get different types back is below, for reference:

You’ll notice that you can’t append KeyPath or its subclasses with AnyKeyPath or PartialKeyPath, unless you upcast the first KeyPath to one of those type erased variants too. I’m not sure why these weren’t included. My best guess is that the swift team didn’t want developers to accidentally move into a type-erased world when they didn’t intend to, and upcasting would force developers to consciously opt-in to that behavior.

And so much more!

Well, three things more. You can use optional chaining to model optional properties in the same way it works by directly referencing them:

struct Person {  var address: Address? } struct Address {  var fullAddress: String } let kp = \Person.address?.fullAddress // returns WritableKeyPath<Person, String?>

However I haven’t found a way to append KeyPaths with optionals somewhere in the chain. If a KeyPath ends in an optional Value, it’s unclear to me how you would append a KeyPath to that since you can’t (as far as I know) create a KeyPath that would lift its types up to an optional Root and Value directly. I expect explicit compiler or standard library support would need to be added to make this work.

You can also ostensibly use subscripting in KeyPaths:

struct Person {  var previousAddresses: [Address] } let kp = \Person.previousAddresses[0].fullAddress // WritableKeyPath<Person, String>

However as of the swift snapshot in Xcode 9 beta 6, this isn’t working (with an actually useful error message saying that it’s not implemented yet).

There’s also ostensibly a way to use inferred types in key paths:

let p: Person = ... p[keyPath: \.name] // \.name should evaluate to WritableKeyPath<Person, String>, // referencing the name property on Person since we're calling it on an instance of Person

However this also appears to not be implemented yet (with a much less useful error message). I expect it will make it into Swift 4.1 if it’s too late for it to get into Swift 4.0 (as of this article’s publishing).

Conclusion

KeyPaths are a really cool feature that I haven’t heard discussed that much in the Swift developer community. I expect that more people will get excited about them once Swift 4 is released and people have more chances to play with them. There’s a lot of cool stuff in Foundation that utilizes the feature too that’s beyond the scope of this post (which I’ll probably get to in the future).

original source : https://stackoverflow.com/questions/44447032/what-is-a-keypath-used-for

https://stackoverflow.com/a/44466557/3151712

Objective-C has the ability to reference a property dynamically rather than directly. These references, called keypaths. They are distinct from direct property accesses because they don't actually read or write the value, they just stash it away for use.

Let define a struct called Cavaliers and a struct called Player, then create one instance of each:

// an example struct struct Player {    var name: String    var rank: String } // another example struct, this time with a method struct Cavaliers {    var name: String    var maxPoint: Double    var captain: Player    func goTomaxPoint() {        print("\(name) is now travelling at warp \(maxPoint)")    } } // create instances of those two structs let james = Player(name: "Lebron", rank: "Captain") let irving = Cavaliers(name: "Kyrie", maxPoint: 9.975, captain: james) // grab a reference to the `goTomaxPoint()` method let score = irving.goTomaxPoint // call that reference score()

The last lines create a reference to the goTomaxPoint() method called score. The problem is, we can't create a reference to the captain's name property but keypath can do.

let nameKeyPath = \Cavaliers.name let maxPointKeyPath = \Cavaliers.maxPoint let captainName = \Cavaliers.captain.name let cavaliersName = irving[keyPath: nameKeyPath] let cavaliersMaxPoint = irving[keyPath: maxPointKeyPath] let cavaliersNameCaptain = irving[keyPath: captainName]