Feature/methods over operators

[Przemyslaw-Wosko]

Hi, This is just refactor proposal for ongoing issue with slow infering .

I've also created regular expression to replace most of operator usage with method. It still have to be perfected but basic idea works really nice :)

I'd be perfect if we could use those regular expression in SwiftLint autocorrect

// search: [a-w].Anchor == (.)Anchor.* // replace: constraint($1, $2)

[chrisballinger]

Considering this comments out a large section of convenience operators, I'm not sure if it can be merged without this significantly impacting the functionality that the library provides.

If we were to merge something like this, we'd need to preserve the existing functionality without breaking backwards compatibility and provide alternatives for hot spot areas.

I wonder if we could achieve similar type checking gains without losing the expressiveness by using less ambiguous/overloaded operators like #== instead of == or something.

[ZevEisenberg]

For fun, we could use ⩵, which is U+2A75 "TWO CONSECUTIVE EQUALS SIGNS" :trollface:

For serious, it looks like you can't use # for operators, but, this is a list of valid characters for operators. You'd want to use something near the top of the list that is easy to type and unlikely to be overridden. & and % come to mind, so &>=, &==, &<= or %>=, %==, %<=. I don't love it, but you can get used to anything. Could also maybe do ^.

It would also be nice to investigate doing the operators as a sub-pod, or leaving them in but providing an option not to use them. Does it slow down compiles just to have Anchorage's operators in the project, or do they actually have to be used?

Final thought: we should definitely profile build times before making such a drastic change, and probably also have an intermediate release that deprecates the old operators or something like that.

[Przemyslaw-Wosko]

@chrisballinger this was only proposal, i've copied Anchorage.swift, named it AnchorageAsMethods.swift and just replaced overloads for == operator with method in new file. That doesn't break anything. I still planned to add methods for other operators, but first i wanted to make sure that we want to move forward in that direction.

@ZevEisenberg looking for other operator would be something that won't fix issue. If i remember correctly, its rather about type inferring in operators, and you can calculate complexity like that: where n is number of types in project, number of operations that compiler have to do, to infer type: n^3 - n so for whole project i'd be usages * n^3 -n

It would also be nice to investigate doing the operators as a sub-pod, or leaving them in but providing an option not to use them. Does it slow down compiles just to have Anchorage's operators in the project, or do they actually have to be used?

Its about usage, not existence in project, so for now, seems like perfect solution would be to finish my PR, add also methods for other operators and allow to coo-exist methods and operators.

In our large project i've replaced 800 usages of == operator and autocompletion worked good for me, also compilation speed up, i can't say how much, because we are using cocoapods and app is separated to main project + modules which contains views, and those cocoapods modules are cached so i'd assume that i optimized only 300 usages in main project in incremental builds. It speed up 15% and there is no more issue with xcode autocompletion. That works perfect for us 🏎

Funny fact is that is you still can use == operator, then you can just run replace with those regular expressions i've added to migrate to method syntax :D

Please let me know if i should finish PR and add parallel API for other operators or you want to move in other direction. Also help would be appreciated, especially in finding new names for operators like >= and -

[ZevEisenberg]

@Przemyslaw-Wosko digging a little deeper on this, I'm curious which aspects of Anchorage you're finding useful other than the operator syntax? As a few people pointed out to me offline, there are several popular Auto Layout libraries out there that don't use custom operators.

[Przemyslaw-Wosko]

@ZevEisenberg

First and most important is that we have large codebase that uses Anchorage, i don't want to spend 2 days going through 800 usages in codebase

Second important fact is that anchorage adds some functionality, like endgesAnchor or something like that, and we want to speed up project a little bit without having to re-test entire application. So its rather about having changes that won't bite us on release.

Those two are most important for now and team just likes using this library so we can still use it for development and then from time to time run regex to replace operators with methods :D

I'd love to hear answer whatever this proposal will go forward

[chrisballinger]

We ended up taking an alternate route, there are now some less overloaded operators: #93