What's the best Swift pattern for returning a pending PromiseKit promise if one is already in running?

Question

I have some expensive promises that get called in different spots. Ideally, I'd like to just chain off an existing in-flight promise (with an optional force), so I find myself doing something like this:

class Expensive {
  var fooPromise : Promise<Foo>?
  var barPromise : Promise<Bar>?

  func doExpensiveFoo(force: bool = false) -> Promise<Foo> {
    if let existing = fooPromise where existing.pending || (existing.fufilled && !force) {
      // Return the existing promise
      return existing
    }

    // Start a new Foo
    return firstly {
       // ...
    }
  }

  func doExpensiveBar(force: bool = false) -> Promise<Bar> {
    if let existing = barPromise where existing.pending || (existing.fufilled && !force) {
      // Return the existing promise
      return existing
    }

    // Start a new Bar
    return firstly {
       // ...
    }
  }
}

But that feels like a fair amount of boiler-plate (a local variable for each promise, and the existing chunk at the start of each function), so I'm wondering if anyone has seen a good pattern for abstracting away the variables and wrapper?

To borrow a term from Python, I'm looking for a decorator that would hide all that. Something like:

class Expensive {

  private func startFoo() -> Promise<Foo> {
    return firstly {
       //..
    }
  }

  public doExpensiveFoo = wrapExpensive(startFoo)

}

Any suggestions, or should I look at rolling my own?

Answer 1

I'm no expert, but this pattern worked for me:

private var fooPromise : Promise<Foo>?

func doExpensiveFoo() -> Promise<Foo> {
    if let fooPromise = self.fooPromise, fooPromise.isPending {
        // return the pending promise
        return fooPromise
    }

    // reassign a newly created promise
    fooPromise = firstly { 
        // do your thing
        ...
    }

    return fooPromise!
  }

What I like about this pattern is that the method handles pending state internally, and that the promise automatically re-executes if called after it is finished. This allows callers to be ignorant of the internal mechanism or the state of the promise. Obviously, if you need to caller to be part of the decision, then keep the "force" flag approach.

Answer 2

I do not see any common base of Foo and Bar in your example. But even if they would have one Swift still does not support covariance on generic type parameters. At first you would need to create a common protocol for both types. Maybe this helps you to get on track:

Storing generic objects in Swift Array