Closed pogramos closed 3 years ago
Cool!
Though, that PR renames constrain
to cg_constrain
- so the README would be different if I merged that. Which do you prefer?
using cg_constrain
would do no harm, but it would be good if the old functions were deprecated instead of directly renaming it... considering that there could be some projects using the framework without a version lock, it could cause lots of crashes, so IMO we could use something like:
@available(swift, deprecated: 5.1, renamed: "cg_constrain")
on the old functions to point out that it will not be supported in the near future and users should migrate to this naming convention. So later on those functions could be safely removed.
What do you think?
I've put some thought on it, and I think we should not rename constrain
to cg_constrain
, since we have Swift's modularity to play on our side;
Using Cartography.constrain
just like a namespace
would be a benefit in some ways since we'll always know where that constrain
function came from.
IMO we could just leave it as is, and just push the docs update.
This is a doc update with the usage hints, based on the problems found in Xcode 11 and as stated in this Pull Request #314