> On Jul 14, 2016, at 3:44 AM, Karl <razie...@gmail.com> wrote:
>
> I just discovered this thread by accident - thank the Lord I’m not the only
> one who feels like this about the new Dispatch API!
>
>> On 8 Jul 2016, at 04:16, Darren Mo via swift-evolution
>> <swift-evolution@swift.org> 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 <darren...@me.com> wrote:
>>>
>>> On Jun 21, 2016, at 5:28 PM, Matt Wright <m...@apple.com> wrote:
>>>>> On Jun 20, 2016, at 5:50 PM, Darren Mo via swift-evolution
>>>>> <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!
>>>
To somewhat follow up on Darren’s suggestion: after internal discussion, moving
`.after` into `.async` isn’t as good an idea as I had hoped. The behaviour of
`.after`, both in execution and performance, differ substantially from `.async`.
>
> So long as the signature then reads grammatically - I had a little battle
> about this yesterday:
> http://comments.gmane.org/gmane.comp.lang.swift.evolution/23867
>
> To summarise:
> - “after” should take a plain time interval
> - “deadline” is just simply the wrong word - means something else entirely
> - since we can’t take an interval without a clock, we need a default clock
> - but the nuances with those clocks are very important and a source of subtle
> bugs, so we should also ask for precise intention
>
> => I think we should split DispatchQueue.after() based on clock type. This
> would allow us to provide a default value for “now”, meaning we can also
> accept plain time intervals, as the resulting API would be explicit about the
> clock nuances that are often overlooked.
I don’t think this topic needs forking and rehashing on this thread too.
>
>>>>> 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.)
>
> I would also like to know this. I really don’t like typing Dispatch... every
> time. It doesn’t seem to be very forgiving with code-completion.
This was covered somewhat during initial evolution, after discussion with the
core team we decided to keep the Dispatch prefix. Several of the class names
make more contextual sense with a Dispatch prefix, where they would not
otherwise; Queues, Groups, etc. Secondly, Dispatch is implicitly imported by
Foundation and we feel that keeping the prefix is clearer to the developer what
it is you’re actually using.
>
> Also, dispatch code tends to contain a fair amount of nested closures. It’s
> nice to keep the line lengths short in that case.
>
> Karl
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
