[swift-evolution] [Review] SE-0023 API Design Guidelines
Dave Abrahams
dabrahams at apple.com
Tue Jan 26 14:08:43 CST 2016
on Mon Jan 25 2016, Radosław Pietruszewski <swift-evolution at swift.org> wrote:
> Paul, let’s start a new thread about this — I was going to write about
> the same idiom, but it’s out of scope of this review.
>
> I disagree with Dave that this is just a EDSL,
I didn't say *just* an EDSL! EDSLs are hugely important.
> I think things like completion/success/failure handlers are a very
> common pattern,
That doesn't make it "not an EDSL."
> and it would be great to have consistent naming and a Guidelines
> recommendation for them. (Usually in the context of argument names,
> not chainable methods, which are, indeed, quite DSL-y).
Here's the problem: I don't want to make special rules for this one kind
of EDSL, because the next declarative language that comes along will
have the same problem with the guidelines. I wouldn't mind saying
something like, "mutating methods that are declarative in nature might
not be verbs."
>
>
> — Radek
>
>> On 25 Jan 2016, at 04:48, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>
>> Siesta uses the widespread fluent style of attaching callbacks to a request:
>>
>> resource.load()
>> .onCompletion { _ in stopSpinnyThing() }
>> .onSuccess { _ in showHappyFace() }
>> .onFailure { _ in showSadFace() }
>> .onNewData { _ in soundTrumpets() }
>>
>> These methods mutate the receiving request (by adding a callback), and the guidelines thus say that they should be named as imperative verbs. The results of that don’t seem like an improvement:
>>
>> resource.load()
>> .addCompletionCallback { _ in stopSpinnyThing() }
>> .addSuccessCallback { _ in showHappyFace() }
>> .addFailureCallback { _ in showSadFace() }
>> .addNewDataCallback { _ in soundTrumpets() }
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Dave
More information about the swift-evolution
mailing list