Reactivecocoa: Comment devons-nous gérer les préfixes `rac_` dans Swift 3 ?

Nous pourrions supprimer les préfixes puisque les types rendent les noms sans ambiguïté, du moins dans la plupart des cas. Ou nous pourrions les garder. Je suis sur la clôture.

Si nous les conservons, nous devrions utiliser rac_ ici (y compris le code de Rex) et trouver un nouveau préfixe pour ReactiveSwift.

Étant donné que la suppression du préfixe des liaisons provoquerait des collisions de noms avec les propriétés stockées, une alternative serait d'introduire un proxy qui les hébergerait toutes.

par exemple

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`.

(Ou juste rac ? Mais ReactiveSwift et ReactiveCocoa pourraient exposer une sorte de liaisons, je suppose)

... Ou nommez-le simplement view.textProxy , view.reactiveText ou autre, hein.

Edit : j'ai mis en place un prototype rapide (https://github.com/RACCommunity/Rex/pull/143).

Edit 2: Nettoyez un peu le désordre. :p

ReactiveCocoa 5+ n'a pas besoin d'être compatible avec Rex. RAC englobera Rex.

Bien sûr, je voulais juste dire ces liaisons apportées par Rex. Désolé si ça se lit comme un gâchis. ??

outlets serait aussi un concurrent.

"réactif" est mieux avec un langage rapide. "rac_" et "rex_" sont de très mauvais noms. Je choisirai "réactif", "actif" ou "signal" afin que nous puissions avoir view.reactiveText ou view.activeText ou view.signalText

Avec Swift et ses modules, il n'y a plus de risque de collisions d'exécution, et donc plus besoin de préfixes. Alors laissons-les tomber ! :RÉ

C'est bien pour les méthodes. Mais nous devons encore chercher une approche pour les propriétés, car les propriétés ne peuvent pas être surchargées. ??

Construit sur un proxy bindable par exemple view.bindables.something , nous pouvons introduire des raccourcis comme %view.something . ??

Je pense qu'il est prudent de tirer la conclusion que nous ne pouvons en aucun cas éviter / lever l'ambiguïté des collisions au moment de la compilation, du moins dans Swift 3.0. Des suggestions telles que l'utilisation d'opérateurs ou de propriétés magiques limitent simplement le potentiel de collision à une entité.

Je risquerais une collision avec un opérateur en échange d'une plus belle sténographie cependant...

Je pense que nous sommes coincés avec des préfixes pour les propriétés pour le moment.

L'une des choses que nous avons faites avec SnapKit est de créer une structure qui héberge les extensions, les API RAC pourraient être stockées comme :

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

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

Suivre cette voie offre une certaine flexibilité et réduit la portée de collision des extensions.

Oui, je l'ai déjà évoqué avec une version basée sur un protocole. Il remplace le trait de soulignement par un point et permet l'introduction d'un raccourci opérateur. L'OMI utiliserait rac comme nom de propriété, car ce n'est pas une abréviation très courante de toute façon.

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

rac propriété aurait l'air tellement plus propre… TELLEMENT MUUUCH !!! :heart_eyes:

Je pense que nous devrions voler l'approche adoptée par RxSwift.

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

Ils ont ajouté une structure, Reactive qui est générique sur le type qu'ils souhaitent étendre. Ils ont ensuite ajouté des méthodes sur les extensions contraintes à Reactive . De toute évidence, ils ont modélisé cela d'après le .lazy Swift.

Ce n'est peut-être pas du vol.

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