I'm not convinced that perform is clearer than async.
performAndWait *is* clearer than sync but only in context: you wouldn't know
perform was async until you read it or noticed the difference with
performAndWait. Nothing about *perform* on its own conveys that it's
asynchronous.
Brandon
Sent from my iPad
On Jun 20, 2016, at 10:05 PM, Brent Royal-Gordon via swift-evolution
<swift-evolution@swift.org> wrote:
>> DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)
>> --------------------------------------------------------------
>> The lack of verb in the base name bothers me. The API Design Guidelines say
>> “methods with side-effects should read as imperative verb phrases”. You
>> could argue that the argument label “execute” serves as the verb. However,
>> .async and .sync are most commonly used with trailing closures where the
>> argument label is not present.
>>
>> This issue was brought up during the review, but I did not see it being
>> addressed. Why not name the methods something like .executeAsync(_:) and
>> .executeSync(_:)?
>
> That feels a little redundant to me. It's worth remembering that the API
> Guidelines are a means of creating clear APIs, not an end in themselves. It's
> okay to deviate a little if you get a better result.
>
> However, I could see us borrowing (and slightly modifying) terminology from
> Core Data:
>
> queue.perform { … }
> queue.performAndWait { … }
>
> Compared to the status quo, this is clearer, a better fit for the guidelines,
> and better at penalizing the disfavored API.
>
>> DispatchQueue.after(when:execute:)
>> ----------------------------------
>> This one simply doesn’t read grammatically. For example, `queue.after(when:
>> .now) { … }` becomes “queue, after when now …”. Since dispatch_after is
>> semantically just an extended version of dispatch_async (I think), we can
>> name this .executeAsync(after:_:).
>
> Yeah, I gave a talk about the renaming on Saturday and somebody noted that
> `when` reads poorly here. Fortunately, `queue.perform(after: .now() + 0.5)`
> reads pretty well too. :^)
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
