Sollten Nicht-Instanz-Methoden freie Funktionen oder statische Funktionen sein?
Denn aktuell haben wir:
extension SignalType {
/// Merges the given signals into a single `Signal` that will emit all values
/// from each of them, and complete when all of them have completed.
@warn_unused_result(message="Did you forget to call `observe` on the signal?")
public static func merge<S : SequenceType where S.Generator.Element == Signal<Value, Error>>(signals: S) -> ReactiveCocoa.Signal<Self.Value, Self.Error>
}
Aber wir haben auch:
/// Combines the values of all the given signals, in the manner described by
/// `combineLatestWith`.
@warn_unused_result(message="Did you forget to call `observe` on the signal?")
public func combineLatest<A, B, Error>(a: Signal<A, Error>, _ b: Signal<B, Error>) -> Signal.Signal<(A, B), Error>
Wir sollten für RAC 5.0 auf das eine oder andere standardisieren.
Ich würde für kostenlose Funktionen stimmen, aber ich bin neugierig, ob jemand der Meinung ist, dass wir statische Funktionen verwenden sollten. @Reaktiver Kakao/reaktiver Kakao
Statische Funktionen sind autocomplete-freundlicher, also würde ich dafür stimmen.
Danke, dass du das erwähnt hast :) stimme definitiv zu, dass wir uns aus Konsistenzgründen vereinen sollten!
Ein Vorteil der kostenlosen Funktionen besteht darin, dass Sie nicht darüber nachdenken müssen, ob etwas ein Signal
oder ein SignalProducer
.
Ich stimme @JaviSoto zu. Für Leute, die RAC gut kennen, sind kostenlose Funktionen kein Problem, ich würde argumentieren, dass die Auffindbarkeit für Anfänger bis mittlerer Ebene ein Problem sein kann.
Die Swift-API-Richtlinien sind diesbezüglich ziemlich klar .
Bevorzugen Sie Methoden und Eigenschaften gegenüber freien Funktionen. Freie Funktionen werden nur in Sonderfällen verwendet:
Wenn es kein offensichtliches Selbst gibt:
min(x, y, z)
Wenn die Funktion eine uneingeschränkte generische Funktion ist:
print(x)
Wenn die Funktionssyntax Teil der etablierten Domänennotation ist:
sin(x)
Diese Funktionen sind im Grunde genommen schicke Konstruktoren, daher scheint die Verwendung des Metatyps als self
vertretbar.
Dies wurde in #3001 gemacht! 🎉
Hilfreichster Kommentar
Die Swift-API-Richtlinien sind diesbezüglich ziemlich klar .
Diese Funktionen sind im Grunde genommen schicke Konstruktoren, daher scheint die Verwendung des Metatyps als
self
vertretbar.