facebookarchive / KVOController

Simple, modern, thread-safe key-value observing for iOS and OS X.
Other
7.34k stars 925 forks source link

Accidental use of the NSObject+FBKVOController.h in Swift? #121

Open winzig opened 7 years ago

winzig commented 7 years ago

The docs state:

For an even easier usage, just #import <KVOController/NSObject+FBKVOController.h> for an automatic KVOController property on all objects.

I am using Swift and I don't want that behavior, but it seems as though I am getting it now in Xcode 8.1 with Swift 3. I have installed KVOController 1.2.0 using CocoaPods. In a couple Swift files I have imported the library with:

import KVOController

To my knowledge I have not explicitly imported NSObject+FBKVOController.h, though I'm guessing it must be happening as part of the way this is getting utilized by Swift? Is there a way to prevent this?

winzig commented 7 years ago

The way I noticed this is after updating to Swift 3 and getting the latest Pods for my project, I began testing/compiling and was getting weird issues that my use of kvoController variables in a couple classes was trying to override an existing variable.

nlutsenko commented 7 years ago

Hmm. We can improve this, but clashes are sort of in-evitable when it comes to using ObjC. kvoController or rather KVOController is quite a unique name, that we didn't think it was possible to clash on it.

We could introduce a sub-spec, meaning that you will be able to select which part you want explicitly.

In the meantime, the workaround for your case would be to simply copy/paste the FBKVOController.h/.m to your project instead of going via CocoaPods, hence the library is small enough.

winzig commented 7 years ago

OK, gotcha. It's not so much the collision I was worried about, but just assuming there is some (in my case unwanted) overhead from having the category in place on all my NSObjects.

nlutsenko commented 7 years ago

Since it's lazy loaded, unless you explicitly invoke it - there should be no visible cost to having it.