[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