Reactivecocoa: 我们应该如何处理 Swift 3 中的 `rac_` 前缀？

创建于 2016-07-10 · 15评论 · 资料来源: ReactiveCocoa/ReactiveCocoa

Swift API 指南设定了小驼峰案例的约定。

目前，我们在 Swift 代码库中有两个例外： NotificationCenter.rac_notifications(forName:object:)和URLSession.rac_data(with:) 。此外，由于 IIRC 我们将在某个时候将 Rex 作为 Cocoa Bindings 存储库的一部分合并，因此也应该考虑如何处理rex_前缀。

我们应该遵循，还是保持原样？

对于这个 repo 中的两个扩展，最没有创意的名字可能是`makeProducer` 。
工厂方法的名称以“make”开头，例如xmakeIterator()。
编辑：三思而后行，对于生产者来说，他们在开始之前没有任何副作用。因此，描述它将提供什么的非变异名称将是合适的 IMO，例如只是`notifications(forName:object:)` 。

资料来源

andersio

最有用的评论

我们使用 SnapKit 所做的一件事是创建一个托管扩展的结构，RAC api 可以像这样存储：

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

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

沿着这条路线走可以提供一些灵活性并减少扩展的冲突范围。

robertjpayne 于 2016-08-09

👍5 ❤2

所有15条评论

我们可以删除前缀，因为类型使名称明确——至少在大多数情况下。或者我们可以保留它们。我在篱笆上。

如果我们保留它们，我们应该在这里使用rac_ （包括来自 Rex 的代码）并为 ReactiveSwift 找到一个新的前缀。

mdiep 于 2016-07-11

由于删除绑定的前缀会导致与存储的属性发生名称冲突，因此另一种方法是引入一个代理来承载所有这些属性。

例如

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：清理一下混乱。 :p

andersio 于 2016-07-11

ReactiveCocoa 5+ 不需要与 Rex 兼容。 RAC 将包含 Rex。

mdiep 于 2016-07-11

当然，我只是指 Rex 带来的那些绑定。对不起，如果它读起来像一团糟。 😸

andersio 于 2016-07-11

outlets也将是一个竞争者。

andersio 于 2016-07-12

“reactive”更适合使用 swift 语言。 “rac_”和“rex_”是非常糟糕的命名。我会选择“reactive”、“active”或“signal”，这样我们就可以有 view.reactiveText 或 view.activeText 或 view.signalText

bobgodwinx 于 2016-07-15

使用 Swift 和模块，不再有运行时冲突的风险，因此不需要前缀。所以让我们放弃他们吧！ :D

NachoSoto 于 2016-07-18

👍2

方法很好。但是我们仍然需要为属性寻找一种方法，因为属性不能被重载。 😕

建立在`bindable`代理上，例如`view.bindables.something` ，我们可以引入像`%view.something`这样的快捷方式。 😕

andersio 于 2016-07-18

我认为可以安全地得出结论，我们不能以任何方式避免/消除编译时冲突，至少在 Swift 3.0 中是这样。使用运算符或魔法属性之类的建议只会将碰撞的可能性限制在一个实体上。

我会冒着操作员碰撞的风险来换取更好的速记...

andersio 于 2016-07-25

我认为我们现在坚持使用属性前缀。

mdiep 于 2016-07-26

我们使用 SnapKit 所做的一件事是创建一个托管扩展的结构，RAC api 可以像这样存储：

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

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

沿着这条路线走可以提供一些灵活性并减少扩展的冲突范围。

robertjpayne 于 2016-08-09

👍5 ❤2

是的，我以前用基于协议的版本提出过它。它用点代替下划线，并允许引入操作符简写。 IMO 使用rac作为属性名称就可以了，因为无论如何它都不是一个非常常见的缩写。

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

andersio 于 2016-08-09

👍1

rac财产看起来会更干净...... SOOO MUUUCH !!! ：心眼：

iby 于 2016-08-14

我认为我们应该借鉴 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 。

mdiep 于 2016-09-19

👍1

或许不是偷窃。

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

andersio 于 2016-09-19

😄1

此页面是否有帮助？

0 / 5 - 0 等级

Reactivecocoa: 我们应该如何处理 Swift 3 中的 `rac_` 前缀？

最有用的评论

所有15条评论

编辑：我已经建立了一个快速原型（https://github.com/RACCommunity/Rex/pull/143）。编辑2：清理一下混乱。 :p

建立在bindable代理上，例如view.bindables.something ，我们可以引入像%view.something这样的快捷方式。 😕

相关问题

编辑：我已经建立了一个快速原型（https://github.com/RACCommunity/Rex/pull/143）。
编辑2：清理一下混乱。 :p

建立在`bindable`代理上，例如`view.bindables.something` ，我们可以引入像`%view.something`这样的快捷方式。 😕