Re: Translating KVO-ed property to Swift

[Jean-Daniel]

Just a tough that go in the ‘always use dynamic’ side. I think setter 
interposition is not the only issue with KVO. KVO also need to be able to fetch 
the old property value when -willChange: is called. I’m not sure about how it 
does that, but I’m pretty confident it will break if the getter is not properly 
exposed in Obj-C, which may be the case if the property is neither declare 
@objc, nor dynamic.

> Le 20 avr. 2017 à 22:06, Quincey Morris  
> a écrit :
> 
> On Apr 20, 2017, at 10:24 , Charles Srstka  wrote:
>> 
>> I mean, yes, we could go all the way down to explaining how everything works 
>> in terms of the physics and chemistry of electrons and semiconductors, but 
>> that wouldn’t be very practical, would it?
> 
> I subscribe to the principle already quoted from the documentation: If you 
> KVO-observe a property, mark it “dynamic”. I like this because it is simple 
> and unambiguous. If anyone asked me for advice, I’d say to follow this 
> principle and don’t agonize any further.
> 
> As a different discussion, at a different level, I agree that there are 
> scenarios where you can omit “dynamic” and still get all the KVO 
> notifications you wanted. What scenarios? Well, I think the essence of your 
> argument is that it can be omitted for a KVO-observed *dependent* property. 
> That at least sounds pretty plausible to me, and it may even be true by 
> definition. If anyone asked you for advice, then I guess you’d say to accept 
> this as an extension of the documented principle. Me, I’m not 100% certain 
> about this, if for no other reason than the documented principle is 
> future-proof against a change in the way things work where Apple says, “Well, 
> we told to you mark all KVO-observed properties dynamic.” But, people can go 
> for advice where they want.
> 
> Where I disagree is in your much stronger claim that a computed property is 
> *necessarily* a dependent property. I think this is just false. The Swift 
> distinction between computed and stored properties is syntactic and has 
> nothing to do with KVO**. A KVO-observed computed property should therefore, 
> according to the documented principle, be marked “dynamic”. For anyone 
> following your extended principle, if it’s also a dependent property, they 
> can omit the “dynamic”. If not, not.
> 
> 
> ** Indeed, it’s trivially easy to convert a public stored property into a 
> public computed property that uses a private, stored, non-KVO-observed 
> property as its instance storage.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Translating KVO-ed property to Swift

[Quincey Morris]

On Apr 20, 2017, at 10:24 , Charles Srstka  wrote:
> 
> I mean, yes, we could go all the way down to explaining how everything works 
> in terms of the physics and chemistry of electrons and semiconductors, but 
> that wouldn’t be very practical, would it?

I subscribe to the principle already quoted from the documentation: If you 
KVO-observe a property, mark it “dynamic”. I like this because it is simple and 
unambiguous. If anyone asked me for advice, I’d say to follow this principle 
and don’t agonize any further.

As a different discussion, at a different level, I agree that there are 
scenarios where you can omit “dynamic” and still get all the KVO notifications 
you wanted. What scenarios? Well, I think the essence of your argument is that 
it can be omitted for a KVO-observed *dependent* property. That at least sounds 
pretty plausible to me, and it may even be true by definition. If anyone asked 
you for advice, then I guess you’d say to accept this as an extension of the 
documented principle. Me, I’m not 100% certain about this, if for no other 
reason than the documented principle is future-proof against a change in the 
way things work where Apple says, “Well, we told to you mark all KVO-observed 
properties dynamic.” But, people can go for advice where they want.

Where I disagree is in your much stronger claim that a computed property is 
*necessarily* a dependent property. I think this is just false. The Swift 
distinction between computed and stored properties is syntactic and has nothing 
to do with KVO**. A KVO-observed computed property should therefore, according 
to the documented principle, be marked “dynamic”. For anyone following your 
extended principle, if it’s also a dependent property, they can omit the 
“dynamic”. If not, not.


** Indeed, it’s trivially easy to convert a public stored property into a 
public computed property that uses a private, stored, non-KVO-observed property 
as its instance storage.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Translating KVO-ed property to Swift

[Charles Srstka]

> On Apr 19, 2017, at 9:12 PM, Quincey Morris 
>  wrote:
> 
> On Apr 19, 2017, at 15:49 , Charles Srstka  wrote:
>> 
>> Cocoa automagically does its secret subclass thing to wrap the setter and 
>> call the didChange/willChange calls for any property you didn’t tell it not 
>> to do. It needs the property to be dynamic for this to work. 
> 
> Yes, that’s almost exactly what I said**. But it still doesn’t make the 
> “dynamic” keyword an on/off switch. Again, the KVO notifications aren’t 
> activated *because* the method has the Swift-specific dynamic attribute, but 
> because the method uses Obj-C dispatching. The “dynamic” keyword [currently] 
> forces the method to use Obj-C dispatching, but the reverse isn’t true. In 
> the absence of the keyword, there’s nothing formally stopping the compiler 
> from using Obj-C dispatching if it chooses to.
> 
> At some level, though, I’m prepared to stipulate that it’s a distinction 
> without much practical difference.

The statement didn’t say anything about “dynamic” being an “on/off switch.” The 
statement that you were quibbling was that you can mark a stored property as 
‘dynamic’, and Cocoa will do the rest. It didn’t say anything about what 
*causes* it, it was meant to be a practical guide to how to implement KVO 
properties in Swift. And to make Cocoa automatically handle the 
didChange/willChange calls, you mark a property as dynamic. I mean, yes, we 
could go all the way down to explaining how everything works in terms of the 
physics and chemistry of electrons and semiconductors, but that wouldn’t be 
very practical, would it?

>> I should add that if a computed property needs ‘dynamic’ in order for its 
>> notifications to fire, the property is not properly KVO-compliant.
> 
> It’s impossible to say in general what counts as a change to a mutable 
> property. Indeed it’s perfectly possible for a property to exist for the 
> purpose of generating KVO notifications without having any meaningful value, 
> and there are plenty more un-generalizable considerations:

The entire purpose of KVO is to monitor changes to values. The word “value” is 
literally right there in the title, as well as most of the major APIs that make 
it work. observeValue. willChangeValue. didChangeValue. value(forKey:). 
setValue. keyPathsForValuesAffecting. Using KVO without a meaningful value is, 
frankly, using a hammer to drive in a screw. For a value-less notification, 
something like NSNotificationCenter is a much better choice.

> — It’s up to an individual property (with a meaningful value) to decide 
> whether KVO notifications are issued when the setter is called (in effect, 
> the default case) or when the value actually changes (as in Rick’s original 
> code), or under some other conditions (e.g. I can imagine a property limiting 
> the rate of notifications using a timer).

Which does not require a property to be dynamic, and in fact would require 
*disabling* Cocoa’s use of dynamism for the property, via returning false for 
automaticallyNotifiesObserversOf.

> — There’s no general presumption whether the value returned by the getter is 
> synchronized with the value passed to the setter.

The setter, however, is likely to make some kind of change to the underlying 
storage such that we will be notified of it. And if no such change is made, 
then there is little point in sending change notifications.

> — There’s no general presumption whether the value returned by the getter is 
> synchronized with the notification, in a multi-threaded environment.

Assuming you’re referring to the fact that something in another thread could 
change the property in the middle of your observer, this still has little that 
I can see to do with the ‘dynamic’ keyword.

> — There’s no general presumption that KVO notifications originate in the 
> property's setter at all, or in the setter only.
> 
> Etc. “keyPathsForValuesAffecting…”-style dependencies are just a convenient 
> short-cut to a specific, simple, typical behavior.

Who said there was?

The bottom line with KVO notifications is that you’ll get one when either:
1. willChange and didChange get called for the property you’re 
watching, or
2. willChange and didChange get called for something that the property 
you’re watching is dependent on.

In case 1, you can either call willChange or didChange yourself, or you can let 
Cocoa do it for you. In Swift, you need to mark it ‘dynamic’ for the latter to 
happen.

In case 2, you don’t need willChange or didChange to get called for your 
property, because we will already get notified when the dependency’s willChange 
and didChange get called. In fact, we might not want them to, because it’ll 
cause the notification to double-post—once in the setter, and then again in the 
dependency’s setter, as in the example below:

> import Foundation
> 
> class Foo: NSObject {
>   @objc dynamic var bar: String = ""
>  

tvOS Siri Universal Search

[Eric E. Dolecki]

Yesterday's news:
The new TV app Apple introduced last fall as a central, Siri-searchable
library of videos from various apps has now signed on Cartoon Network. Its
content now supports Universal Search, single sign-on, and recommendations
on iPhone, iPad and 4th generation Apple TV.

Is this Siri Univeral Search still a custom-Apple solution? I am still
looking for a way to ask my tvOS app to find something using my app's name
to guide the experience (YouTube on tvOS does this). I haven't found
anything, save performing a search within my tvOS application. I like the
elegance of being able to be anywhere to make a request to my application.

Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com