Reactivecocoa: Konvertieren Sie freie Funktionen in statische Funktionen

Erstellt am 23. Mai 2016  ·  5Kommentare  ·  Quelle: ReactiveCocoa/ReactiveCocoa

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

Hilfreichster Kommentar

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.

Alle 5 Kommentare

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! 🎉

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

gabro picture gabro  ·  5Kommentare

Lewion picture Lewion  ·  4Kommentare

RuiAAPeres picture RuiAAPeres  ·  3Kommentare

tunidev picture tunidev  ·  3Kommentare

eimantas picture eimantas  ·  6Kommentare