Re: Translating KVO-ed property to Swift

> On Apr 24, 2017, at 1:17 PM, Quincey Morris > wrote: > > On Apr 24, 2017, at 10:11 , Charles Srstka > wrote: >> >> What Quincey seemed to be referring to was a property that was not backed by >> any kind of persistent value. > > That wasn’t actually the kin

Re: Translating KVO-ed property to Swift

On Apr 24, 2017, at 10:11 , Charles Srstka wrote: > > What Quincey seemed to be referring to was a property that was not backed by > any kind of persistent value. That wasn’t actually the kind of property I had in mind. I was thinking of settable, computed properties that did not depend on the

Re: Translating KVO-ed property to Swift

> On Apr 24, 2017, at 10:07 AM, Richard Charles wrote: > >> >> On Apr 23, 2017, at 11:27 AM, Charles Srstka > > wrote: >> >>> On Apr 20, 2017, at 3:06 PM, Quincey Morris >>> >> > wrote: >>> >>> Where I disagree is in

Re: Translating KVO-ed property to Swift

> On Apr 23, 2017, at 11:27 AM, Charles Srstka wrote: > >> On Apr 20, 2017, at 3:06 PM, Quincey Morris >> wrote: >> >> 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 betw

Re: Translating KVO-ed property to Swift

Sorry I didn’t get around to replying sooner; I’ve had a busy past few days. > On Apr 20, 2017, at 3:06 PM, Quincey Morris > wrote: > > On Apr 20, 2017, at 10:24 , Charles Srstka > wrote: >> >> I mean, yes, we could go all the way down to explaining how everyt

Re: Translating KVO-ed property to Swift

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 n

Re: Translating KVO-ed property to Swift

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 quot

Re: Translating KVO-ed property to Swift

> 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 p

Re: Translating KVO-ed property to Swift

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 exact

Re: Translating KVO-ed property to Swift

> On Apr 19, 2017, at 4:50 PM, Quincey Morris > wrote: > >> 3. Computed properties do not need to be dynamic, […]. > > This is also not exactly true. Computed properties that have only a getter do > not need to be dynamic, because they don’t generate any KVO notifications via > a setter, and

Re: Translating KVO-ed property to Swift

> On Apr 19, 2017, at 4:50 PM, Quincey Morris > wrote: > > On Apr 19, 2017, at 10:56 , Charles Srstka wrote: >> >> 2. Stored properties need to call willChangeValue(forKey:) and >> didChangeValue(forKey:). >> a. In most cases, just add “dynamic” to the property declaration, and >> Cocoa

Re: Translating KVO-ed property to Swift

On Apr 19, 2017, at 10:56 , Charles Srstka wrote: > > 2. Stored properties need to call willChangeValue(forKey:) and > didChangeValue(forKey:). > a. In most cases, just add “dynamic” to the property declaration, and > Cocoa will automagically insert the needed calls. The problem with say

Re: Translating KVO-ed property to Swift

> On Apr 17, 2017, at 7:40 AM, Jean-Daniel wrote: > >> Le 17 avr. 2017 à 10:52, Quincey Morris > > a écrit : >> >> On Apr 17, 2017, at 01:43 , Jean-Daniel > > >>

Re: Translating KVO-ed property to Swift

Thanks, Charles, that's helpful. In the end I left the class as Obj-C, because I still had to derive from it in Obj-C and you annoyingly can't do that. > On Apr 17, 2017, at 08:06 , Charles Srstka wrote: > >> On Apr 17, 2017, at 3:24 AM, Rick Mann wrote: >> >> I have a number of properties in

Re: Translating KVO-ed property to Swift

On Apr 17, 2017, at 12:03 , Charles Srstka wrote: > > You cannot guarantee that the property will be called via objc_msgSend, which > is important if you’re relying on the swizzled accessor to send the property > notifications. If you’re sending them yourself, it doesn’t matter one way or > an

Re: Translating KVO-ed property to Swift

> On Apr 17, 2017, at 1:09 PM, Quincey Morris > wrote: > > On Apr 17, 2017, at 05:40 , Jean-Daniel wrote: > >> This is a good practice, but I don’t think this is required for computed >> property, especially if you take care of willChange/didChange manually, as >> the OP does. > > Here is w

Re: Translating KVO-ed property to Swift

On Apr 17, 2017, at 05:40 , Jean-Daniel wrote: > This is a good practice, but I don’t think this is required for computed > property, especially if you take care of willChange/didChange manually, as > the OP does. Here is what the Swift interoperability documentation says (https://developer.a

Re: Translating KVO-ed property to Swift

> On Apr 17, 2017, at 3:24 AM, Rick Mann wrote: > > I have a number of properties in Objective-C written like this, > short-circuiting notifications when the value doesn't change: > > - > @synthesize version = mVersion > > - (void) > setVersion: (NSString *) inVersion > { >if (

Re: Translating KVO-ed property to Swift

> Le 17 avr. 2017 à 10:52, Quincey Morris > a écrit : > > On Apr 17, 2017, at 01:43 , Jean-Daniel > wrote: >> >> var version: String? { > > A slight correction: this declaration actually must be: > >> dynamic var version: String? { > > > otherwise KVO isn’t gu

Re: Translating KVO-ed property to Swift

On Apr 17, 2017, at 01:43 , Jean-Daniel wrote: > > var version: String? { A slight correction: this declaration actually must be: > dynamic var version: String? { otherwise KVO isn’t guaranteed to work in Swift. ___ Cocoa-dev mailing list (Cocoa-d

Re: Translating KVO-ed property to Swift

On Apr 17, 2017, at 01:24 , Rick Mann wrote: > > I have a number of properties in Objective-C written like this, > short-circuiting notifications when the value doesn't change: Not in this code you don’t, unless you have a “automaticallyNotifiesObserversOfVersion” method returning false elsewh

Re: Translating KVO-ed property to Swift

One way to solve that is to declare an explicit private stored property for the ivar, and a public computed property for the logic. private var _version: String? = nil var version: String? { get { return _version } set { your set version code } } > Le 17 avr. 2017 à 10:24, Rick

Translating KVO-ed property to Swift

I have a number of properties in Objective-C written like this, short-circuiting notifications when the value doesn't change: - @synthesize version = mVersion - (void) setVersion: (NSString *) inVersion { if (inVersion == nil && mVersion == nil) { return; } if