<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 20, 2016 at 9:05 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)<br>
> --------------------------------------------------------------<br>
> 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.<br>
><br>
> 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(_:)?<br>
<br>
</span>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.<br></blockquote><div><br></div><div>The guideline that methods should "read as imperative verb phrases" applies to the full name, labels and arguments and all, and not just the base name. You'll recall that the original proposal had .asynchronously(execute:), which is very much an imperative phrase. `.async(execute:)` was substituted by popular demand, with "async" being regarded as a term-of-art exception.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, I could see us borrowing (and slightly modifying) terminology from Core Data:<br>
<br>
queue.perform { … }<br>
queue.performAndWait { … }<br>
<br>
Compared to the status quo, this is clearer, a better fit for the guidelines, and better at penalizing the disfavored API.<br>
<span class=""><br>
> DispatchQueue.after(when:execute:)<br>
> ----------------------------------<br>
> 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:_:).<br>
<br>
</span>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. :^)</blockquote><div><br></div><div>Or just `queue.after(_:execute:)`, i.e. "after [this time], execute [that routine]."</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</font></span></blockquote></div><br></div></div>