Closed minimusic closed 3 years ago
Maybe matching AutoLayout naming conventions with equalTo
, lessThanOrEqualTo
and greaterThanOrEqualTo
?
matching AutoLayout function names could lead to confusion where you do/don't get the behavior you expect for an identical line of code (depending on which flavor you call)... but it is a direction to consider.
.pin()
, .pinUnder()
, .pinOver()
.set()
, .setMax()
, setMin()
Matching the name would provide limited utility over Apple's layout anchor API. Where we might be able to provide utility is to extend the existing layout anchor API with functions that look the same, but take parameters for multipliers and priority, plus non-operator versions of pinning centerAnchors
, edgeAnchors
, horizontalAnchors
, and verticalAnchors
.
Another angle: since we set translatesAutoresizingMaskIntoConstraints = false
on the left-hand operand, we probably want to distance ourselves from the anchor API because our functions do magic that users of the anchors API are not expecting.
Changing how we write code based on compile times is unfortunate.
My 2cents is that Anchorage has always been about operator syntax for writing layout constraints, and if that changes then it's no longer Anchorage. The limited utility that Anchorage adds over the NSLayoutAnchor API aside from syntax (namely "composite anchors" like edgeAnchors
and centerAnchors
) could easily be ported to a separate, much smaller, library as @minimusic says. I also feel that AnchorageFast.swift
is misleading because "fast" almost always implies faster runtimes, which I don't believe is the case here.
We ended up taking an alternate route, there are now some less overloaded operators: #93
Resolving
==
types seems to really slow down build times on large projects. One idea is to provide an alternate set of anchorage functions that can replace==
,<=
,>=
, etc. So instead ofviewA.topAnchor == viewB.topAnchor
you would sayviewA.topAnchor.pin(viewB.topAnchor)
or something like that. I think there is still added value from Anchorage implementation, but maybe we should also consider a lighter-weight constraint helper to use with the newer/better Apple APIs (just addingedgeAnchors
type conveniences, for example).AnchorageFast.swift extends all the anchoragable classes. Not able to see a build time difference in the demo app, but it is a pretty small code base. Not sure about the
match()
naming. Also consideredpin()
orset()
or some other variant ofequals()
. Would love to come up with an ideal set of names that are more clear in function, but relatively brief.Still need to:
~
or+
, etc.)