Reactivecocoa: ¿Cómo debemos lidiar con los prefijos `rac_` en Swift 3?

Podríamos eliminar los prefijos ya que los tipos hacen que los nombres sean inequívocos, al menos en la mayoría de los casos. O podríamos quedarnos con ellos. Estoy en la valla.

Si los conservamos, deberíamos usar rac_ aquí (incluido el código de Rex) y buscar un nuevo prefijo para ReactiveSwift.

Dado que eliminar el prefijo de los enlaces provocaría colisiones de nombres con las propiedades almacenadas, una alternativa sería introducir un proxy que las aloje todas.

p.ej

view.bindables.text <~ property

// `view.bindables` is of type `Bindings<UIView>`, which conforms to `BindingsProtocol`
// that requires an associated type `Owner`.
//
// `view.bindables.text` is provided by the extension to `BindingsProtocol` for all
//`Owner` inherited from `UIView`.

(¿O solo rac ? Pero tanto ReactiveSwift como ReactiveCocoa podrían exponer algún tipo de enlaces, supongo)

... O simplemente llámalo view.textProxy , view.reactiveText o lo que sea, eh.

Editar: he creado un prototipo rápido (https://github.com/RACCommunity/Rex/pull/143).

Edición 2: Limpia el desorden por un momento. :pag

ReactiveCocoa 5+ no necesita ser compatible con Rex. RAC subsumirá a Rex.

Claro, solo me refiero a esas fijaciones traídas por Rex. Lo siento si se lee como un desastre. 😸

outlets sería un contendiente.

"reactivo" se adapta mejor con un lenguaje rápido. "rac_" y "rex_" son nombres muy malos. Iré por "reactivo", "activo" o "señal" para que podamos tener view.reactiveText o view.activeText o view.signalText

Con Swift y los módulos ya no existe el riesgo de colisiones en tiempo de ejecución y, por lo tanto, no es necesario utilizar prefijos. ¡Así que dejémoslos! :D

Está bien para los métodos. Pero aún debemos buscar un enfoque para las propiedades, ya que las propiedades no se pueden sobrecargar. 😕

Construido sobre un proxy bindable por ejemplo, view.bindables.something , podemos introducir atajos como %view.something . 😕

Creo que es seguro sacar la conclusión de que no podemos evitar / eliminar la ambigüedad de las colisiones en tiempo de compilación de ninguna manera, al menos en Swift 3.0. Sugerencias como el uso de operadores o propiedades mágicas simplemente limitan el potencial de colisión a una entidad.

Sin embargo, me arriesgaría a una colisión con el operador a cambio de una taquigrafía más agradable ...

Creo que por ahora estamos atrapados con prefijos para propiedades.

Una de las cosas que hemos hecho con SnapKit es crear una estructura que aloje las extensiones, las api de RAC podrían almacenarse como:

struct UIButtonRACDSL {
    var pressed: Signal<UIButton, NoError>
    init(button: UIButton) { }
}

extension UIButton {
    var rac: UIButtonRACDSL { return UIButtonRACDSL(button: self) }
}

Seguir esta ruta proporciona cierta flexibilidad y reduce el alcance de colisión de las extensiones.

Sí, lo mencioné antes con una versión basada en protocolo. Reemplaza el guión bajo con un punto y permite la introducción de un operador taquigráfico. En mi opinión, usar rac como nombre de propiedad estaría bien, ya que de todos modos no es una abreviatura muy común.

https://github.com/RACCommunity/Rex/pull/143

rac propiedad

Creo que deberíamos robar el enfoque que ha adoptado RxSwift.

https://github.com/ReactiveX/RxSwift/blob/4952adb27c684b47792923b00015516849061eab/RxCocoa/Common/Reactive.swift
https://github.com/ReactiveX/RxSwift/blob/4952adb27c684b47792923b00015516849061eab/RxCocoa/iOS/UIControl%2BRx.swift

Agregaron una estructura, Reactive que es genérica sobre el tipo que quieren extender. Luego agregaron métodos en extensiones restringidas a Reactive . Evidentemente, modelaron esto después de .lazy Swift.

Quizás no sea robar.

https://github.com/RACCommunity/Rex/pull/143/commits/86f03c3b2d4759c87254a9ea3b28939f23f6be56
😜