> On 10 Aug 2014, at 4:35 am, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > 1. Don’t forget to mark your observable methods and properties as ‘dynamic’ > (new in the latest beta). > > Now that I think about it, though, I hate this “enhancement”. It turns > something that’s relatively simple to use (bindings or KVO) into something > that’s obscure for Cocoa newbies, and gives us one more housekeeping task to > forget, even if we’re newbies. >
I've been trying to understand the implications of dynamic and @objc to work out if we do now have to mark properties written in Swift, usable from objective-C, as dynamic in order for them to be KVO-able. I think you're right here and you do. I'm assuming that Swift calling an ObjC method written in ObjC has to use obj_msgSend because that's all the ObjC code knows. When ObjC calls a method in Swift (which must be marked @objc implicitly or explicitly) it uses objc_msgSend because that's all it knows, and the Swift method supports that. That leaves Swift calling a Swift method which is also marked @objc. If I have understood properly, up until beta 4 that also used objc_MsgSend and was fully dynamic, as of beta 5 it may or may not use objc_MsgSend or it may optimize around it. Only if you mark a Swift method as 'dynamic' is it guaranteed to always be dynamic (which currently also means use objc_MsgSend as that's the only dynamic runtime there is at this point). If that's all correct then it seems that, as observing a property swizzles the class methods so that sets to the value cause a KVO notification to go out, if you write such a property in Swift and mark it only @objc then it's quite possible Swift will call the original, unswizzled methods, and you won't get your notification .. because objc_MsgSend may not be used. I understand the desire to reduce fully dynamic dispatch as much as possible, thats's good. KVO was always a little bit magical, you had to use a KVO-compliant way of mutating the property (how many messages have we seen about that over the years) and you never knew if any given property of someone else's class was or was not mutated in a KVO compliant way, however KVO was quite deeply baked in to the runtime and kind of just worked and now it looks like it's going to not quite just work. Perhaps only old-timers use KVO :) Now it looks more like you have to know if you want a property to be KVO observable you need to make it dynamic. I guess on the flipside, if a property is marked dynamic you could sure that it's KVO compliant because the after KVO has swizzled the setter, there's no other way to set the property but than to call it, so that might be good. If this is where we are then it would be handy to have the runtime throw, or at least log, if you attempt to KVO a Swift property which isn't dynamic. _______________________________________________ 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
