Adding swiftier syntax for DataStack.perform methods #154

Closed
opened 2025-12-29 15:25:51 +01:00 by adam · 2 comments
Owner

Originally created by @sidmani on GitHub (Aug 7, 2017).

Based on the way Swift 3 reworked GCD's async methods, I think it would be convenient to add some syntactic sugar so that this:

dataStack.perform(asynchronous: { transaction in 
// ...
}, completion: { _ in })

can be written like this:

dataStack.async { transaction in 

}

I've been using a simple extension that does this already:

extension DataStack {
    func async<T>(closure: @escaping (AsynchronousDataTransaction) throws -> T) {
        self.perform(asynchronous: closure, completion: { _ in })
    }
}

I can write up a pull request if you like the idea (waiting on #182 though, since I'm working on the swift-4 branch).

Originally created by @sidmani on GitHub (Aug 7, 2017). Based on the way Swift 3 reworked GCD's async methods, I think it would be convenient to add some syntactic sugar so that this: ``` dataStack.perform(asynchronous: { transaction in // ... }, completion: { _ in }) ``` can be written like this: ``` dataStack.async { transaction in } ``` I've been using a simple extension that does this already: ``` extension DataStack { func async<T>(closure: @escaping (AsynchronousDataTransaction) throws -> T) { self.perform(asynchronous: closure, completion: { _ in }) } } ``` I can write up a pull request if you like the idea (waiting on #182 though, since I'm working on the swift-4 branch).
adam closed this issue 2025-12-29 15:25:51 +01:00
Author
Owner

@JohnEstropia commented on GitHub (Aug 8, 2017):

Thank you for the suggestion!

CoreStore's API design is leaned towards brevity more than convenience.

It was a conscious design to require either completion: or success:failure: arguments for async transactions as I don't want to encourage people to ignore errors. (This is also reflected by perform(synchronous:) being a throws method). Doing so, writing completion: { _ in } can explicitly communicate that the error handing was intentionally (as opposed to accidentally) ignored.

In principle, convenience at the cost of safety should be opt-out and is the developer's responsibility.

That said, of course you are free to use the helper methods such as yours in your own projects :)
(I have a couple in my own projects too)

@JohnEstropia commented on GitHub (Aug 8, 2017): Thank you for the suggestion! CoreStore's API design is leaned towards brevity more than convenience. It was a conscious design to require either `completion:` or `success:failure:` arguments for async transactions as I don't want to encourage people to ignore errors. (This is also reflected by `perform(synchronous:)` being a `throws` method). Doing so, writing `completion: { _ in }` can explicitly communicate that the error handing was intentionally (as opposed to accidentally) ignored. In principle, convenience at the cost of safety should be opt-out and is the developer's responsibility. That said, of course you are free to use the helper methods such as yours in your own projects :) (I have a couple in my own projects too)
Author
Owner

@sidmani commented on GitHub (Aug 8, 2017):

Good point, in my situation transaction errors are safe to ignore but that's not necessarily the case.

@sidmani commented on GitHub (Aug 8, 2017): Good point, in my situation transaction errors are safe to ignore but that's not necessarily the case.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/CoreStore#154