[swift-server-dev] Next HTTP API meeting

[Paulo Faria]

> Protocols in Swift exist primarily to allow code to operate on multiple
different concrete implementations simultaneously – either with generics as
constraints, or as existentials. In this case, there is no clear reason why
someone would want to write code that handles two separate implementations
of an HTTP API at the same time within a single program.

I completely agree with this. Using protocols to allow multiple
implementations in this scenario would not be a solution for a technical
problem. It would be, instead, a solution for a "human" problem which is
basically the difficulty of reaching an agreement. In the end what we all
want is the best solution technically.

On 22 March 2017 at 10:19, Ben Cohen via swift-server-dev <
swift-server-dev at swift.org> wrote:

>
> On Mar 20, 2017, at 11:11 PM, Logan Wright via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
> I'd personally like to see us more explicitly explore protocols, I haven't
> seen anything so far that actually requires a concrete model and would
> perhaps be an easier way for us to reach consensus.
>
>
> Hi Logan,
>
> What is it about protocols that you feel would help here? In general, the
> relationship between concrete implementations and protocols should be that
> the former comes first, then the latter. Start with a concrete type, then
> as you move to multiple diverse implementations, factor out the common
> things that unify those types.
>
> Protocols in Swift exist primarily to allow code to operate on multiple
> different concrete implementations simultaneously – either with generics as
> constraints, or as existentials. In this case, there is no clear reason why
> someone would want to write code that handles two separate implementations
> of an HTTP API at the same time within a single program. Protocols are not
> necessary in order to “swap” implementation A for implementation B. All
> that is needed for this is that the two implementations be source
> compatible i.e. have the same method signatures (protocols are a way of
> helping enforce that, but there are other less performance-consequential
> ways of doing it too).
>
> Now, it may be that a need does emerge as the design takes shape to have
> separate types, say, for different kinds of HTTP connections, that might
> need to be handled by the same program and have to be unified via a
> protocol to enable handling code to be shared across both. But this
> protocol should be discovered through the process of looking at the common
> features the different concrete types have, rather than designed up front.
>
> Cheers,
> Ben
>
>
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170322/f8d1677f/attachment.html>