> On Jun 20, 2016, at 7:12 PM, Xiaodi Wu via swift-evolution
> <[email protected]> wrote:
>
>
>
> On Mon, Jun 20, 2016 at 9:05 PM, Brent Royal-Gordon via swift-evolution
> <[email protected]> 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.
>
> 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.
Right, the naming here strayed from the guidelines here under the term-of-art
exception. None of the various alternatives really fit amazingly well, the
async{,hronous} part of the API name communicates an important facet of what
the call does. In that it goes away and executes the closure “somewhere else”.
I feel this particular point is lost in example such as perform{andWait}.
`.asynchronously` was an attempt to move towards the guidelines but it still
missed that mark. I believe it’s still clearer to have `.async` as an exception.
>
> 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. :^)
>
> Or just `queue.after(_:execute:)`, i.e. "after [this time], execute [that
> routine].”
.after is already going to need some tweaking as I don’t believe the current
incarnation is sufficiently named to avoid being ambiguous in the common case.
Though, removing the label will also not help in that regard. I agree, there is
probably merit in the idea of moving after to being an optional argument on
`.async`.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
