vhesener
commented
5 years ago I'm sure you've given it some thought, property wrappers may save a ton of this boiler plate but more importantly be potentially a lot safer! In the midst of updating the tests I noticed a mismatched case, totally easy to do accidentally with such repetitive, dense code. Also means the tests might need to be elaborated on and test actual one to one calling.
@yoiang ...continuing the last PR convo in this PR
I have not considered property wrappers, but it takes creative folks from the outside (such as yourself) to think of some of this stuff, so thank you for the idea. I have never been satisfied with essentially exhausting every delegate method, but that seemed to be the only way to not leave out anyone using an obscure delegate method. This is why the unit tests are mostly sanity checks to make sure the number of delegate methods hasn't change with OS updates. I actually used a custom code generation script (since discarded) to generate most of the library boiler plate.
Being that this is the first time considering it, I can't immediately think of a way to use property wrappers in this fashion. Most examples in the blogosphere use anecdotes related to value constraining, so I'm having trouble thinking of a way to signature constrain. If you can think of just one example of replacing the method calls with a property wrapper, even if just pseudocode, let me know and it may spark an epic refactor that greatly reduces the amount of code in this repo. That would be an amazing feat.
Having said all that, I feel like this library will shortly become irrelevant once SwiftUI has become mainstream. SwiftUI has mostly added declaration or closures to almost every new UIKit equivalent and I'm excited for that to occur actually.
vs #50 as per requested!