Should I create a bug report for changing `DispatchQueue.after` and `DispatchSource.read`?
Darren > On Jun 21, 2016, at 7:35 PM, Darren Mo <darren...@me.com> wrote: > > On Jun 21, 2016, at 5:28 PM, Matt Wright <m...@apple.com > <mailto:m...@apple.com>> wrote: >>> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
