Reactivecocoa: Swift3の `rac_`プレフィックスをどのように処理する必要がありますか？

タイプによって名前が明確になるため、プレフィックスを削除できます。少なくともほとんどの場合です。 または、それらを保持することもできます。 私は柵の上にいます。

それらを保持する場合は、ここでrac_ （Rexのコードを含む）を使用して、ReactiveSwiftの新しいプレフィックスを見つける必要があります。

バインディングのプレフィックスを削除すると、保存されているプロパティと名前が衝突するため、これらの代わりに、すべてをホストするプロキシを導入することもできます。

例えば

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

（または単にrac ？しかし、ReactiveSwiftとReactiveCocoaの両方が何らかのバインディングを公開する可能性があると思います）

...または、 view.textProxy 、 view.reactiveTextなどの名前を付けます。

編集：簡単なプロトタイプをまとめました（https://github.com/RACCommunity/Rex/pull/143）。

編集2：混乱を少しクリーンアップします。 ：NS

ReactiveCocoa5 +はRexと互換性がある必要はありません。 RACはレックスを包含します。

確かに、私はレックスによって持ち込まれたそれらのバインディングを意味しました。 それが混乱のように読めば申し訳ありません。 😸

outletsも候補になります。

「リアクティブ」は、迅速な言語でより優れたスイートです。 「rac_」と「rex_」は非常に悪い名前です。 「reactive」、「active」、または「signal」を選択して、view.reactiveText、view.activeText、またはview.signalTextを作成します。

Swiftとモジュールを使用すると、実行時の衝突のリスクがなくなるため、プレフィックスは不要になります。 だから、それらをドロップしましょう！ ：NS

メソッドには問題ありません。 ただし、プロパティはオーバーロードできないため、プロパティのアプローチを探す必要があります。 😕

bindableプロキシ（ view.bindables.somethingなど）に基づいて構築されているため、 bindable %view.somethingようなショートカットを導入する場合があります。 😕

少なくともSwift3.0では、コンパイル時の衝突を回避/明確化することはできないという結論を導き出すのは安全だと思います。 演算子や魔法のプロパティを使用するなどの提案は、衝突の可能性を1つのエンティティに制限するだけです。

私はより良い速記と引き換えにオペレーターの衝突の危険を冒します...

今のところ、プロパティのプレフィックスに固執していると思います。

SnapKitで行ったことの1つは、拡張機能をホストする構造体を作成することです。RACAPIは次のように保存できます。

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

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

このルートを進むと、ある程度の柔軟性が得られ、拡張機能の衝突範囲が縮小されます。

ええ、私は以前にプロトコルベースのバージョンでそれを持ち出しました。 アンダースコアをドットに置き換え、演算子の省略形を導入できるようにします。 とにかくあまり一般的な略語ではないため、プロパティ名としてracを使用するIMOは問題ありません。

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

racプロパティはとてもきれいに見えるでしょう…すっごくMUUUCH !!! ：heart_eyes：

RxSwiftが採用したアプローチを盗むべきだと思います。

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

彼らは、拡張したい型に対してジェネリックである構造体Reactiveを追加しました。 次に、制約付き拡張機能のメソッドをReactive追加しました。 明らかに、彼らはこれをSwiftの.lazyをモデルにしています。

おそらくそれは盗んでいない。

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