On Jun 21, 2016, at 5:28 PM, Matt Wright <[email protected]> wrote:
>> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution 
>> <[email protected]> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to