Feel free to create one for .read, I already have a radar that covers .after

> On Jul 7, 2016, at 7:16 PM, Darren Mo <[email protected]> wrote:
> 
> Should I create a bug report for changing `DispatchQueue.after` and 
> `DispatchSource.read`?
> 
> Darren
> 
>> On Jun 21, 2016, at 7:35 PM, Darren Mo <[email protected]> wrote:
>> 
>> 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