Reactivecocoa: Convert free functions to static functions

Created on 23 May 2016  ·  5Comments  ·  Source: ReactiveCocoa/ReactiveCocoa

Should non-instance methods be free functions or static functions?

Because currently we have:

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>
}

But we also have:

/// 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>

We should standardize on one or the other for RAC 5.0.

I'd vote free functions, but I'm curious if someone thinks we should be using static functions. @ReactiveCocoa/reactivecocoa

Most helpful comment

The Swift API guidelines are pretty clear on this.

Prefer methods and properties to free functions. Free functions are used only in special cases:

When there’s no obvious self:
min(x, y, z)

When the function is an unconstrained generic:
print(x)

When function syntax is part of the established domain notation:
sin(x)

These functions are basically fancy constructors, so using the metatype as self seems plenty defensible.

All 5 comments

Static functions are more autocomplete-friendly, so I would vote for that.
Thanks for bringing this up :) definitely agree we should unify for consistency!

A benefit of free functions is that you don't need to think about whether something is a Signal or a SignalProducer.

I agree with @JaviSoto. For people that know RAC well, free functions are not an issue, I would argue for novice to mid level discoverability can be an issue.

The Swift API guidelines are pretty clear on this.

Prefer methods and properties to free functions. Free functions are used only in special cases:

When there’s no obvious self:
min(x, y, z)

When the function is an unconstrained generic:
print(x)

When function syntax is part of the established domain notation:
sin(x)

These functions are basically fancy constructors, so using the metatype as self seems plenty defensible.

This was done in #3001! 🎉

Was this page helpful?
0 / 5 - 0 ratings

Related issues

baei2048 picture baei2048  ·  3Comments

gabro picture gabro  ·  5Comments

simonxcheng picture simonxcheng  ·  6Comments

BrettThePark picture BrettThePark  ·  4Comments

danishin picture danishin  ·  4Comments