<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Fri, Dec 16, 2016, at 06:30 AM, Charles Srstka wrote:<br></div>
<blockquote type="cite"><blockquote type="cite">On Dec 16, 2016, at 12:36 AM, Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>> wrote:<br></blockquote><div><blockquote type="cite"><div><br></div>
<div><div><div>On Thu, Dec 15, 2016, at 03:01 PM, Charles Srstka wrote:<br></div>
<blockquote type="cite"><blockquote type="cite">On Dec 15, 2016, at 4:33 PM, Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>> wrote:<br></blockquote><div><blockquote type="cite"><div><br></div>
<div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">The problem with that code isn't that `dynamic` doesn't work for computed properties. It does; if you mutate the `foo` property, you'll get the KVO notifications. The problem is you have one property that depends on another and you didn't set up the KVO machinery properly using automaticallyNotifiesObservers(forKey:) or automaticallyNotifiesObserversOf<key>() (incidentally in Swift you can write the latter as a `static let`, since that becomes a class method in Obj-C).</span></span><br></div>
</blockquote><div><br></div>
<div>You’ll only get the notifications if you mutate ‘foo’ directly. This, however, is fairly useless, because if you are watching ‘foo’, you want to be notified every time the value changes, not just when someone hits one particular accessor. Code relying on observation of ‘foo’ in the example I provided would be prone to breaking in mysterious and possibly horrible ways.<br></div>
</div>
</blockquote><div><br></div>
<div>No, if you implement keyPathsForValuesAffecting<key>() then you get "foo" KVO notifications when "bar" is mutated. That's the whole point of that method, and this is exactly what you have to do in Obj-C as well.<br></div>
</div>
</div>
</blockquote><div><br></div>
<div>Right… the sentence I was quoting was talking about code which uses ‘dynamic’ but *doesn’t* use keyPathsForValuesAffecting<key>. You’ll get notifications if someone calls that one particular accessor, but otherwise you won’t.<br></div>
</div>
</blockquote><div><br></div>
<div>You can always write buggy code. If you're using `dynamic` for KVO purposes, then not implementing keyPathsForValuesAffecting<Key> in this case is strictly a bug. If you're using `dynamic` for something other than KVO, and your property won't end up supporting KVO properly by default, then you should document it as such, given that the natural assumption for a `dynamic` property is that it supports KVO.</div>
<div><br></div>
<blockquote type="cite"><div><blockquote type="cite"><div><div><blockquote type="cite"><div><blockquote type="cite"><div><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">So yes, `dynamic` by itself doesn't mean that the property supports KVO. But there are very few reasons to use `dynamic` outside of supporting KVO, so it's a pretty good signal that the property does support it. And conversely, not having `dynamic` doesn't mean that it doesn't support KVO, though if it does have manual KVO support using will/didChangeValue(forKey:) then it should be documented as such.</span></span><br></div>
</blockquote><div>Use of the ‘dynamic’ keyword enables all manner of runtime hackery which someone may be employing. The trick to automatically add KVO conformance to accessors is probably the most common, but it’s hardly the only one. One also might want to declare things ‘dynamic’ when working with Objective-C frameworks not under one’s control which might assume the ability to do metaprogramming on your classes<br></div>
</div>
</blockquote><div><br></div>
<div>That is exceedingly rare. I can't even remember the last time I used such a thing.<br></div>
</div>
</div>
</blockquote><div><br></div>
<div>You used such a thing the last time you used KVO. ;-)<br></div>
</div>
</blockquote><div><br></div>
<div>We were talking about metaprogramming other than KVO.</div>
<div><br></div>
<blockquote type="cite"><div><blockquote type="cite"><div><div><blockquote type="cite"><div><div>I know it’s commonplace to use ‘dynamic’ all over the place wherever Core Data is involved.<br></div>
</div>
</blockquote><div><br></div>
<div>It is? Why? Maybe you're confusing this with Obj-C's @dynamic keyword, which is completely unrelated to Swift's `dynamic`. When writing Swift NSManagedObject subclasses, you use the @NSManaged property attribute, not the `dynamic` keyword (@NSManaged does effectively the same thing that Obj-C's @dynamic, except it's reserved for integration with CoreData instead of being as generic as Obj-C's @dynamic is).<br></div>
</div>
</div>
</blockquote><div><br></div>
<div>@NSManaged implies dynamic, though. Core Data is entirely built on the dynamic runtime, and is using it pretty much everywhere.<br></div>
</div>
</blockquote><div><br></div>
<div>@NSManaged could easily be implemented by codegenning static-dispatch methods that invoke the primitive accessors and will/didChange KVO broadcasts. Presumably it doesn't (presumably it does literally the same thing @dynamic does in Obj-C, which is that it makes the assumption that the methods exist at runtime even though they're unknown at compile-time), but there's nothing about @NSManaged that requires it to always use dynamic dispatch. Core Data leverages the dynamic runtime for method generation, but it doesn't actually require it (you can completely ignore dynamicism and implement your properties in terms of primitiveValue(forKey:) and setPrimitiveValue(_:forKey:), though the dynamically-synthesized primitive accessors are supposed to be more efficient).<br></div>
<div><br></div>
<blockquote type="cite"><div><blockquote type="cite"><div><div><blockquote type="cite"><div><div>Long story short, ‘dynamic’ does not guarantee KVO conformance in any way, shape, or form.<br></div>
</div>
</blockquote><div><br></div>
<div>And declaring that your property returns a String doesn't guarantee that it actually does either. You can always write broken code. But `dynamic` is required for automatic KVO conformance, and it's extremely rare to have a reason to use `dynamic` outside of KVO, so it's a really really strong signal that the property supports KVO. If you're using `dynamic` on a property but don't support KVO correctly, as you showed in your code example, that's a bug with your code.<br></div>
</div>
</div>
</blockquote><div><br></div>
<div>Correlation does not imply causation. Dynamic properties often support KVO, but the developer may have just declared it dynamic in order to use Objective-C’s dynamism to solve some other problem. You don’t know, and thus I certainly wouldn’t call it a bug in the code.<br></div>
</div>
</blockquote><div><br></div>
<div>If a particular language feature is used 99.9% of the time to provide some particular functionality, then people will assume the presence of that language feature implies that functionality. I don't think it's incorrect to assume that the overwhelming majority of uses of `dynamic` are for KVO conformance.<br></div>
<div><br></div>
<div>-Kevin Ballard</div>
<div><br></div>
</body>
</html>