Conversation
…onstraints, and aligning with other views.
…y in the debugger.
There was a problem hiding this comment.
There's nothing wrong with using negative constants in constraints. The original implementation seems cleaner to me.
There was a problem hiding this comment.
The original implementation is cleaner, but it is a leaky abstraction. Users that want to adjust the constant on the constraint need to know when PureLayout decided to make the constraint negative or not. Given that the user passed in a positive constant it seems wrong to make that negative.
That said, users of PureLayout may already have workarounds for using negative constants in certain cases. If we fix this bug it might trip them up.
Also, keeping the constant positive makes debugging easier. The constraint prints to the debugger in an easier format (I wrote that code when I worked on Auto Layout at Apple. Sorry I didn't just detect this other case...)
There was a problem hiding this comment.
A positive inset does not imply that the constant on the underlying constraint will be positive. It's deterministic when the constant will be positive and when it will be negative. And the important point is that this change would be breaking for all existing users because it will cause the constant to flip signs as well as the first and second items on the constraint to swap half the time.
As far as debugging, shouldn't we file a radar so Apple improves this?
2 participants
This adds convenience methods for the common case of two child views separated by some space. They are common enough that the Auto Format Format Language was specially suited to them, with the format "[red]-[blue]".
These are a little tricky to create by hand if you want the constant space to be positive. For example,
[orange]-5-[black]isblack.leading = orange.trailing + 5. The black view comes first in the equation. This requires a moment of pause every time I write the constraint by hand.[orange autoPinHorizontalSpace:5 followedByView:black]is more natural.This PR also fixes a bug in
autoPinEdgeToSuperviewEdge: withInset: relation:so the constant is always positive and it prints in the debugger using the Auto Layout Format Language. If it is too risky I can remove it from this PR.