Reactivecocoa: Wie sollen wir mit den `rac_`-Präfixen in Swift 3 umgehen?

Wir könnten die Präfixe weglassen, da die Typen die Namen eindeutig machen – zumindest in den meisten Fällen. Oder wir könnten sie behalten. Ich bin am Zaun.

Wenn wir sie behalten, sollten wir hier rac_ (einschließlich des Codes von Rex) und ein neues Präfix für ReactiveSwift finden.

Da das Löschen des Präfixes der Bindungen Namenskollisionen mit den gespeicherten Eigenschaften verursachen würde, wäre eine Alternative für diese die Einführung eines Proxys, der alle hostet.

z.B

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

(Oder nur rac ? Aber sowohl ReactiveSwift als auch ReactiveCocoa könnten irgendeine Art von Bindungen aufdecken, nehme ich an)

... Oder nennen Sie es einfach view.textProxy , view.reactiveText oder was auch immer, eh.

Edit: Ich habe einen schnellen Prototyp zusammengestellt (https://github.com/RACCommunity/Rex/pull/143).

Bearbeiten 2: Räumen Sie das Chaos ein wenig auf. :P

ReactiveCocoa 5+ muss nicht mit Rex kompatibel sein. RAC wird Rex subsumieren.

Klar, ich meinte nur die Bindungen, die Rex mitgebracht hat. Sorry, wenn es sich wie ein Durcheinander liest. 😸

outlets wäre auch ein Anwärter.

"reactive" ist besser mit schneller Sprache. "rac_" und "rex_" sind sehr schlechte Namen. Ich werde "reaktiv", "aktiv" oder "signal" wählen, also könnten wir view.reactiveText oder view.activeText oder view.signalText haben

Mit Swift und Modulen besteht kein Risiko für Laufzeitkollisionen mehr und daher keine Notwendigkeit für Präfixe. Also lass uns sie einfach fallen lassen! :D

Für die Methoden ist es in Ordnung. Wir müssen aber noch nach einem Ansatz für die Eigenschaften suchen, da Eigenschaften nicht überladen werden können. 😕

Aufgebaut auf einem bindable Proxy zB view.bindables.something , können wir Abkürzungen wie %view.something einführen. 😕

Ich denke, es ist sicher, die Schlussfolgerung zu ziehen, dass wir Kollisionen zur Kompilierzeit in keiner Weise vermeiden/disambiguieren können, zumindest in Swift 3.0. Vorschläge wie die Verwendung von Operatoren oder magischen Eigenschaften begrenzen nur das Kollisionspotenzial auf eine Entität.

Ich würde jedoch eine Operatorkollision riskieren, um eine schönere Kurzschrift zu erhalten ...

Ich denke, wir stecken im Moment bei Präfixen für Eigenschaften fest.

Eines der Dinge, die wir mit SnapKit gemacht haben, ist das Erstellen einer Struktur, die die Erweiterungen hostet. Die RAC-APIs könnten wie folgt gespeichert werden:

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

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

Dieser Weg bietet eine gewisse Flexibilität und reduziert den Kollisionsbereich der Erweiterungen.

Ja, ich habe es schon einmal mit einer protokollbasierten Version angesprochen. Es ersetzt den Unterstrich durch einen Punkt und ermöglicht die Einführung einer Operatorkürzel. IMO wäre die Verwendung von rac als Eigenschaftsname in Ordnung, da dies sowieso keine sehr gebräuchliche Abkürzung ist.

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

rac Eigentum würde so viel sauberer aussehen… SOOO MUT!!! :Herz Augen:

Ich denke, wir sollten den Ansatz von RxSwift stehlen.

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

Sie fügten eine Struktur hinzu, Reactive , die generisch über den Typ ist, den sie erweitern möchten. Anschließend fügten sie Methoden für eingeschränkte Erweiterungen zu Reactive . Offensichtlich haben sie dies nach Swifts .lazy modelliert.

Vielleicht ist es kein Diebstahl.

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