-
Notifications
You must be signed in to change notification settings - Fork 432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Smart Key Paths and Bindings #331
Comments
The current approach seems simplest to me. But we should definitely play around with it once a beta is available |
If you mean maintaining computed properties on The main drivers behind our current design (IIRC) were discoverability and type safety over KVC string key paths after all. Smart Key Path helps address the second, while the first one remains to be seen. |
Just jumping in here as a non-contributer: as someone who has gotten quite used to the current approach, (2) and (4) are very legible. If continuity is a priority then it makes sense to me to reuse |
Implemented by #440 and ReactiveCocoa/ReactiveCocoa#3489. |
With the accepted the Smart Key Paths for Swift 4,
BindingTarget
would be supercharged with the ability to access any properties and their subfields of objects and mutable properties without hand-written closures.It could remove the needs of all binding targets in the reactive extensions. That said it depends on how it would be incorporate in our binding syntaxes.
The most verbose approach would be:
The verbose approach to reuse
reactive
would be:The old-ObjC macro-ish approach would be:
(3) is a serious contender given its brevity as compared to (1). It can also replace
.reactive
as the gateway to the reactive extensions. It also does not suffer as much as.reactive
from cross-module name conflicts, since at least it can still be disambiguated by the module name.The downside is that it violates the Swift API Guidelines, which state that free functions should be used only:
The approach to reuse
reactive
would be:An infix operator based approach would be:
A prefix or postfix operator based approach would be:
There are more combinations, but these are listed based on the requirement of having enough contextual information for autocompletion of key paths to show up in the LTR order.
I suppose most would prefer (4) or (5).
/cc @ReactiveCocoa/reactiveswift
The text was updated successfully, but these errors were encountered: