[swift-server-dev] Next HTTP API meeting
ben_cohen at apple.com
Wed Mar 22 08:19:42 CDT 2017
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-server-dev