[swift-evolution] [SE-0088] Dispatch API names

[Darren Mo]

On Jun 21, 2016, at 5:28 PM, Matt Wright <mww at apple.com> wrote:
>> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution <swift-evolution at swift.org> wrote:
>> 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:_:).
> 
> I replied to messages out of order but I agree, moving `.after` onto .async seems like the more natural place for it to live.

Yay!

>> DispatchSource subclass names
>> -----------------------------
>> Why is it DispatchSourceMemoryPressure instead of MemoryPressureDispatchSource? I don’t think I’ve ever seen subclass names where the superclass part is at the beginning of the name.
> 
> I’m not so keen to remove the Dispatch prefix from the front of the source types, given that we avoided doing that for the remainder of the module.

What is the rationale for keeping the Dispatch prefix anyways? (I couldn’t find it in the archives.)

>> DispatchSource factory methods
>> ------------------------------
>> e.g. DispatchSource.read(fileDescriptor:queue:). The API Design Guidelines mandate that factory methods begin with the prefix “make”. Indeed, DispatchSource.read might mislead people to think that a read will be performed by this method. A better name would be .makeReadSource(fileDescriptor:queue:).
> 
> Agreed, these should probably be brought into line with that guideline.

Yay!

>> And why are these factory methods on DispatchSource instead of initializers on the subclasses? ReadDispatchSource.init(fileDescriptor:queue:) would be way clearer.
> 
> The source types are not subclasses, due to implementation details they are protocols.

Oops, missed that. Sorry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160621/f84a2e18/attachment.html>