Skip to content
This repository has been archived by the owner on Mar 3, 2020. It is now read-only.

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

Open
winzig opened this issue Nov 5, 2016 · 4 comments
Open

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

winzig opened this issue Nov 5, 2016 · 4 comments

Comments

@winzig
Copy link

winzig commented Nov 5, 2016

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
Copy link
Author

winzig commented Nov 5, 2016

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
Copy link
Contributor

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
Copy link
Author

winzig commented Nov 5, 2016

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
Copy link
Contributor

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants
@winzig @nlutsenko and others