uninstall() is internal about snapkit

[cnoon]

The README describes you use case. Here is a section taken directly from it.

var topConstraint: Constraint? = nil

...

// when making constraints
view1.snp_makeConstraints { make in
  self.topConstraint = make.top.equalTo(superview).with.offset(padding.top)
  make.left.equalTo(superview).with.offset(padding.left)
}

...
// then later you can call
self.topConstraint.uninstall()

In the future I would suggest you read through the entire README of an open source project before posting usage and design questions. It will certainly save yourself and others time and frustration.

Hope that helps!

[allen-zeng]

Thanks for your comment.

If you read the question a bit more closely, it's actually about the fact that uninstall() is marked as internal.

The excerpt is what I used as my reference point. Except

• because topConstraint is an Optional so you'd have to unwrap it before calling uninstall()
• coming back to the question, because uninstall() is marked as internal, it can't actually be called from outside of the framework.

So to expand a bit more on my question: are there reasons why we might not want to expose uninstall() publicly? For example, setups required, unintended side effects etc.? If not, then we'll have to update the access modifier to public

[cnoon]

Hey @allen-zeng, sorry about that. I totally read your question way too fast. You make all great points.

The README example is definitely wrong. You definitely would have to unwrap the topConstraint before calling uninstall(). Additionally, it wouldn't compile anyways since uninstall is not public.

@robertjpayne do you have some thoughts here? I'm assuming we'll need to make the uninstall method public, but what about the install method then? It seems weird to only have uninstall marked as public.

[robertjpayne]

Hey @allen-zeng @cnoon in the last update I marked these two methods as internal due to the fact they really shouldn't be used in their current state given they don't clean up properly.

I'll try and get around to this ASAP as in hindsight this wasn't probably a good idea.

[cnoon]

Sounds good dude...thanks for the update @robertjpayne.

[allen-zeng]

Thank you @robertjpayne @cnoon for your help.

Does this mean that ConstraintMaker isn't cleaning up properly? Because internal funcs remakeConstraints and updateConstraints use uninstall.

Are there things we can do (workarounds) to clean up?

[robertjpayne]

ConstraintMaker has extra code to properly clean up so those are just fine!

On 12/01/2015, at 11:12 am, Allen Zeng [email protected] wrote:

Thank you @robertjpayne @cnoon for your help.

Does this mean that ConstraintMaker isn't cleaning up properly? Because internal funcs remakeConstraints and updateConstraints use uninstall.

Are there things we can do (workarounds) to clean up?

—
Reply to this email directly or view it on GitHub.

[allen-zeng]

Phew! Thanks for clearing that up!

[robertjpayne]

@allen-zeng @cnoon this is fixed up now on master, I'm not pushing to pods trunk yet as I need to do some more testing tonight, I'm not 100% happy with how I implemented it but it works for now as far as I can tell.