Translating KVO-ed property to Swift

[Rick Mann]

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 ([inVersion isEqualToString: mVersion])
{
return;
}

[self willChangeValueForKey: @"version"];
mVersion = inVersion;
[self didChangeValueForKey: @"version"];
}
-

Now I want to translate this method into Swift. Thing is, AFAIK you can't name 
the ivar created for a property. Is there a way to translate this to swift?

TIA,

-- 
Rick Mann
rm...@latencyzero.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

[Jean-Daniel]

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 Mann  a écrit :
> 
> 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 ([inVersion isEqualToString: mVersion])
>{
>return;
>}
> 
>[self willChangeValueForKey: @"version"];
>mVersion = inVersion;
>[self didChangeValueForKey: @"version"];
> }
> -
> 
> Now I want to translate this method into Swift. Thing is, AFAIK you can't 
> name the ivar created for a property. Is there a way to translate this to 
> swift?
> 
> TIA,
> 
> -- 
> Rick Mann
> rm...@latencyzero.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/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 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 elsewhere in 
the class. The notification doesn’t happen in the synthesized implementation of 
the setter, but via a swizzled replacement setter that is normally installed 
only when something starts observing the property. Anyway …

> Now I want to translate this method into Swift. Thing is, AFAIK you can't 
> name the ivar created for a property. Is there a way to translate this to 
> swift?

You do it in the “obvious” way — you declare a second, private property without 
a custom getter or setter, and you use this private property where you would 
have used the instance variable in Obj-C. The effect is the same, because the 
private property is optimized into just an instance variable, and the public 
property has no instance storage of its own (but you will have to provide a 
custom getter, too).

___

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

[Jean-Daniel]

> 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 guaranteed to work in Swift.

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.


___

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: Help Indexing

[Jerome Krinock]

> On 2017 Apr 14, at 18:17, Frank D. Engel, Jr.  wrote:
> 
> 

In my Help Book, my working anchors use `id` instead of `name`.  I forgot why.  
Example:

2.3.1  Testing Syncing in Smarky

>NSLog(@"help: '%@'", what);
>NSString *locBookName = [[NSBundle mainBundle] objectForInfoDictionaryKey: 
> @"CFBundleHelpBookName"];
>[[NSHelpManager sharedHelpManager] openHelpAnchor:what inBook:locBookName];

Looks OK but you should log that locBookName too.

If neither of these suggestions fixes the problem, the next level of trouble is 
caching by Apple Help Viewer.  Try running this script, or pieces of it, in 
Terminal.app.

https://github.com/jerrykrinock/DeveloperScripts/blob/master/HelpViewerHammer.sh

I’ve not had to use it in several years, though.  Maybe Apple has fixed the 
caching.
___

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 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 (inVersion == nil && mVersion == nil)
>{
>return;
>}
>if ([inVersion isEqualToString: mVersion])
>{
>return;
>}
> 
>[self willChangeValueForKey: @"version"];
>mVersion = inVersion;
>[self didChangeValueForKey: @"version"];
> }
> -
> 
> Now I want to translate this method into Swift. Thing is, AFAIK you can't 
> name the ivar created for a property. Is there a way to translate this to 
> swift?

I’ve been converting a lot of KVO properties to Swift lately. Here’s how I’d do 
this:

// Only needed if the property will be accessed by Objective-C code, since 
Swift code won’t see the swizzled accessors anyway for a non-dynamic property.
// @objc annotation is needed on every method we write here, since otherwise 
it’ll quit working when @objc inference is removed in Swift 4 (SE-0160)
@objc private static let automaticallyNotifiesObserversOfVersion: Bool = false

// Our actual version property. If you want, you can create a private property 
named “mVersion” and it will function like an instance variable.
// But I’d probably just use willSet and didSet.
// Note that this doesn’t need to be dynamic, since we are not relying on 
Cocoa’s built-in automatic swizzling,
// which is only needed if we are not calling willChangeValue(forKey:) and 
didChangeValue(forKey:) ourselves.
@objc var version: String {
willSet {
// Send the willChange notification, if the value is different from its 
old value.
if newValue != self.version {
self.willChangeValue(forKey: #keyPath(version))
}
}
didSet {
// Send the didChange notification, if the value is different from its 
old value.
if oldValue != self.version {
self.didChangeValue(forKey: #keyPath(version))
}
}
}

Charles

___

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: Reference to embedded view controller in IB?

[Alex Zavatone]

I wrote some stuff to find your view controller within the storyboard and/or 
within the view hierarchy based on the class name of the view controller. 

Some of it is a little new some of it is a little old.

One trick (on iOS) is that you will need to check if your root controller is a 
nav controller or not.  

The way I have seen the tag property used is arbitrary and leads to problems 
and assumptions.  If you plan on using it for this purpose, create an enum with 
all the possible values for your view's tag.  Or create a category on 
UIViewController and add an NSString called controllerIdentifier and a method 
for viewControllerInstanceFromIdentifier which returns what you want when given 
the identifier and only use this within the controllers that require it.

> I have a view controller that I instantiate in my Storyboard. This view
> controller has an embedding view inside it's view, and this embedding
> view has another view controller in it.

inside its* view

I had to beat this into my head, and what I came up with follows.  "In a case 
where it's not clear if the contraction or the possessive should get the 
apostrophe, the contraction wins and gets the apostrophe."

That's how I had to learn it.

- Alex Zavatone

On Apr 5, 2017, at 4:06 PM, Doug Hill wrote:

> Thanks for the follow up.
> I saw this but I happen to have multiple embedded view controllers. While 
> it's possible to do a search, it's more difficult because there are multiple 
> embed view with the same view controller class. Let's say, views are in 
> position 1, 2, and 3 and I want to configure 1, 2,  and 3 differently based 
> on their position.
> I'm thinking of making a outlet to the embedding view and then compare this 
> view with view controllers in childViewControllers. But seems like a lot of 
> busy work It would be great to be able to more easily lookup the view 
> controller for a particular embed view. Any chance?
> 
> Doug Hill
> https://github.com/djfitz/SFFontFeatures 
> 
> 
> 
>> On Apr 5, 2017, at 1:55 PM, Quincey Morris 
>>  wrote:
>> 
>> On Apr 5, 2017, at 13:42 , Doug Hill > > wrote:
>>> 
>>> Can this be done? Are there other ways to get a reference to the embedded 
>>> view controller at runtime?
>> 
>> I believe you’ll find the embedded view controller in the root view 
>> controller’s “childViewControllers” array property.
>> 
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.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 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.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/AdoptingCocoaDesignPatterns.html):

> "You can use key-value observing with a Swift class, as long as the class 
> inherits from the NSObject class. You can use these three steps to implement 
> key-value observing in Swift.
> 
> "1. Add the dynamic modifier to any property you want to observe. […]”

Here is what the Swift language documentation says 
(https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html):

> “dynamic”
> 
> "Apply this modifier to any member of a class that can be represented by 
> Objective-C. When you mark a member declaration with the dynamic modifier, 
> access to that member is always dynamically dispatched using the Objective-C 
> runtime. Access to that member is never inlined or devirtualized by the 
> compiler.”


That is, unless you specify “dynamic” there’s no *guarantee* that invocations 
to the property accessors will use obj_msgSend, and since there’s no way in 
Swift to guarantee that obj_msgSend *won’t* be used for the property, the 
outcome for automatic KVO is unpredictable. 

On Apr 17, 2017, at 08:07 , Charles Srstka  wrote:
> 
> // Note that this doesn’t need to be dynamic, since we are not relying on 
> Cocoa’s built-in automatic swizzling,
> // which is only needed if we are not calling willChangeValue(forKey:) and 
> didChangeValue(forKey:) ourselves.
> @objc var version: String {
>willSet {
>// Send the willChange notification, if the value is different from 
> its old value.
>if newValue != self.version {
>self.willChangeValue(forKey: #keyPath(version))
>}
>}
>didSet {
>// Send the didChange notification, if the value is different from its 
> old value.
>if oldValue != self.version {
>self.didChangeValue(forKey: #keyPath(version))
>}
>}
> }

I tested what happens (in Swift 3.1, Xcode 8.3.1) using this code:

> private var versionContext = 0
> 
> class ViewController: NSViewController {
>   @objc /*dynamic*/ var version: String = “” {
>   willSet {
>   if newValue != self.version {
>   self.willChangeValue (forKey: 
> #keyPath(version)) }
>   }
>   didSet {
>   if oldValue != self.version {
>   self.didChangeValue (forKey: #keyPath(version)) 
> }
>   }
>   }
>   override func viewDidLoad () {
>   super.viewDidLoad ()
>   addObserver (self, forKeyPath: #keyPath(version), options: [], 
> context: &versionContext)
>   }
>   override func observeValue (forKeyPath keyPath: String?,  of object: 
> Any?,  change: [NSKeyValueChangeKey : Any]?,  context: 
> UnsafeMutableRawPointer?) {
>   print ("observedValue for \(version)")
>   }
>   @IBAction func buttonClicked (_ sender: Any?) { // There’s a button in 
> the UI hooked up to this
>   version = version == "" ? "1" : "\(version)"
>   }
> }

This version of the code (with “dynamic” commented out) displays the observer 
message once, as desired, and then not again, as desired. Uncommenting 
“dynamic” causes the message to be displayed twice the first time, and then 
once more every subsequent button click.

So, Charles’s approach *appears* to work, because the “version” property isn’t 
participating in automatic swizzling. However, it’s subtly wrong because 
there’s no way to prevent other source code from leading the compiler to 
*deduce* that the method is dynamic. Once that happens, there’s an extra 
unwanted notification every time the property is set.

And again, in the converse scenario (automatic KVO, where you want 
notifications unconditionally) the “dynamic” keyword isn’t optional.

The correct solution, I claim, is to replace the declaration of “version” with 
this:

>   static func automaticallyNotifiesObserversOfVersion () -> Bool { return 
> false }
>   @objc dynamic var version: String = “” { … }

and then use either Charles’ or Jean-Daniel’s logic to generate the 
notifications manually as desired.

(BTW, the “@objc” is currently redundant, but will soon become required, via 
SE-0160 
.)


___

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.app

Re: Translating KVO-ed property to Swift

[Charles Srstka]

> 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 what the Swift interoperability documentation says 
> (https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/AdoptingCocoaDesignPatterns.html):

And the reason for this is because Cocoa swizzles the accessor and adds the 
willChangeValue() and didChangeValue() calls. If you’re calling these yourself 
(or if you’re a computed property that registers its dependencies via 
keyPathsForValuesAffecting methods), you don’t need dynamic.

>> "You can use key-value observing with a Swift class, as long as the class 
>> inherits from the NSObject class. You can use these three steps to implement 
>> key-value observing in Swift.
>> 
>> "1. Add the dynamic modifier to any property you want to observe. […]”
> 
> Here is what the Swift language documentation says 
> (https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html):
> 
>> “dynamic”
>> 
>> "Apply this modifier to any member of a class that can be represented by 
>> Objective-C. When you mark a member declaration with the dynamic modifier, 
>> access to that member is always dynamically dispatched using the Objective-C 
>> runtime. Access to that member is never inlined or devirtualized by the 
>> compiler.”
> 
> That is, unless you specify “dynamic” there’s no *guarantee* that invocations 
> to the property accessors will use obj_msgSend, and since there’s no way in 
> Swift to guarantee that obj_msgSend *won’t* be used for the property, the 
> outcome for automatic KVO is unpredictable. 

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 
another how the property was called, as long as you add @objc so that clients 
that do expect to be able to use objc_msgSend (most importantly, NSObject’s 
observation support) can do it.

> On Apr 17, 2017, at 08:07 , Charles Srstka  wrote:
>> 
>> // Note that this doesn’t need to be dynamic, since we are not relying on 
>> Cocoa’s built-in automatic swizzling,
>> // which is only needed if we are not calling willChangeValue(forKey:) and 
>> didChangeValue(forKey:) ourselves.
>> @objc var version: String {
>>willSet {
>>// Send the willChange notification, if the value is different from 
>> its old value.
>>if newValue != self.version {
>>self.willChangeValue(forKey: #keyPath(version))
>>}
>>}
>>didSet {
>>// Send the didChange notification, if the value is different from 
>> its old value.
>>if oldValue != self.version {
>>self.didChangeValue(forKey: #keyPath(version))
>>}
>>}
>> }
> 
> I tested what happens (in Swift 3.1, Xcode 8.3.1) using this code:
> 
>> private var versionContext = 0
>> 
>> class ViewController: NSViewController {
>>  @objc /*dynamic*/ var version: String = “” {
>>  willSet {
>>  if newValue != self.version {
>>  self.willChangeValue (forKey: 
>> #keyPath(version)) }
>>  }
>>  didSet {
>>  if oldValue != self.version {
>>  self.didChangeValue (forKey: #keyPath(version)) 
>> }
>>  }
>>  }
>>  override func viewDidLoad () {
>>  super.viewDidLoad ()
>>  addObserver (self, forKeyPath: #keyPath(version), options: [], 
>> context: &versionContext)
>>  }
>>  override func observeValue (forKeyPath keyPath: String?,  of object: 
>> Any?,  change: [NSKeyValueChangeKey : Any]?,  context: 
>> UnsafeMutableRawPointer?) {
>>  print ("observedValue for \(version)")
>>  }
>>  @IBAction func buttonClicked (_ sender: Any?) { // There’s a button in 
>> the UI hooked up to this
>>  version = version == "" ? "1" : "\(version)"
>>  }
>> }
> 
> This version of the code (with “dynamic” commented out) displays the observer 
> message once, as desired, and then not again, as desired. Uncommenting 
> “dynamic” causes the message to be displayed twice the first time, and then 
> once more every subsequent button click.
> 
> So, Charles’s approach *appears* to work, because the “version” property 
> isn’t participating in automatic swizzling. However, it’s subtly wrong 
> because there’s no way to prevent other source code from leading the compiler 
> to *deduce* that the method is dynamic. Once that happens, there’s an extra 
> unwanted notification every time the property is set.

“This approach *appears* to work, but it stops working if I change som

Re: Translating KVO-ed property to Swift

[Quincey Morris]

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 
> another how the property was called, as long as you add @objc so that clients 
> that do expect to be able to use objc_msgSend (most importantly, NSObject’s 
> observation support) can do it.

If you’re sending them yourself, then what matters is that you don’t 
*accidentally* let the property generate automatic notifications as well. There 
is only one way (AFAIK) to *guarantee* that automatic notifications aren’t 
generated as well, and that’s by returning false from 
‘automaticallyNotifiesObserversOfVersion’. There’s no other way in Swift 
(AFAIK) to ensure that, since there’s no “nondynamic” keyword. There’s also no 
other way in Obj-C (AFAIK) to ensure that.

This issue wasn’t supposed to be about Swift, though Swift makes it a bit 
murkier. Rick’s original code was wrong unless he had an Obj-C 
automaticallyNotifiesObserversOfVersion method elsewhere. For all I know, since 
he didn’t weigh back in with more information, he had that method all along.

> You also forgot the automaticallyNotifiesObserversOfVersion property in the 
> first bit of my example.

Yes, sorry, I just didn’t see it tucked up against the comment. Your code was 
correct in every detail.

___

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

[Rick Mann]

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 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 ([inVersion isEqualToString: mVersion])
>>{
>>return;
>>}
>> 
>>[self willChangeValueForKey: @"version"];
>>mVersion = inVersion;
>>[self didChangeValueForKey: @"version"];
>> }
>> -
>> 
>> Now I want to translate this method into Swift. Thing is, AFAIK you can't 
>> name the ivar created for a property. Is there a way to translate this to 
>> swift?
> 
> I’ve been converting a lot of KVO properties to Swift lately. Here’s how I’d 
> do this:
> 
> // Only needed if the property will be accessed by Objective-C code, since 
> Swift code won’t see the swizzled accessors anyway for a non-dynamic property.
> // @objc annotation is needed on every method we write here, since otherwise 
> it’ll quit working when @objc inference is removed in Swift 4 (SE-0160)
> @objc private static let automaticallyNotifiesObserversOfVersion: Bool = false
> 
> // Our actual version property. If you want, you can create a private 
> property named “mVersion” and it will function like an instance variable.
> // But I’d probably just use willSet and didSet.
> // Note that this doesn’t need to be dynamic, since we are not relying on 
> Cocoa’s built-in automatic swizzling,
> // which is only needed if we are not calling willChangeValue(forKey:) and 
> didChangeValue(forKey:) ourselves.
> @objc var version: String {
> willSet {
> // Send the willChange notification, if the value is different from 
> its old value.
> if newValue != self.version {
> self.willChangeValue(forKey: #keyPath(version))
> }
> }
> didSet {
> // Send the didChange notification, if the value is different from 
> its old value.
> if oldValue != self.version {
> self.didChangeValue(forKey: #keyPath(version))
> }
> }
> }
> 
> Charles
> 


-- 
Rick Mann
rm...@latencyzero.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