<div dir="ltr">Hey Everyone,<br><br>I disagree with the premise that protocols inherently create bugs, but would be open to constraining to classes if this alleviates concerns. If we create protocols, this allows frameworks to implement concrete models with whatever semantics they see fit. Any subsequent interaction from the framework would have a concrete type to rely on.<div><br></div><div>In terms of what we're building here, I don't see middleware as much of a responsibility since this should be the tools that a framework would use. I think it's very important for all of us to remember that we're not building a web framework. We're building the tooling to make a good starting point for others to use in development of a web framework.<br><br>If people feel extremely strong that there needs to be a concrete type, then I'd like to push for reference type as much as possible. As far as reference vs value type, I haven't really heard an argument for value types beyond what feels like a reaction to value types being the hip new hotness. While yes, they're great in Swift, and there's tons of places that should absolutely be modeled with value semantics, a request/response interaction represents a single request and should definitely be a reference based interaction.<br><br>In practice, we went through several model iterations and the value type created very high levels of bugs and confusion for end users. The three biggest problems we had were as follows:</div><div><br></div><div>- Greatly increased bug levels and confusion related to unexpected mutation<br>- Unnecessary code requirements added to every single passive access (ie: middleware) increasing code bloat unnecessarily<br>- Extreme performance loss due to massive copy overhead<br><br>Each of these problems evaporated pretty instantaneously when moving to reference types; it made it significantly easier to reason about for end users. <br><br>Summary:<br><br>Would like to remind again for those that skipped above reading that our goal is not to build a web framework here, but rather to build small tools that make building frameworks slightly easier for library maintainers and creators. <br><br>Ideally, we could abstract the memory semantics away and leave them up to frameworks by utilizing protocols .. this is my preference. If however, concrete models are required, I feel reference type is the ideal choice for the reasons outlined above. I believe that a request/response interaction is representative of singular instances that should be referenced by various interactors as opposed to introducing more copy/mutation complexity and a model that doesn't fit with the concept. </div><div><br>Looking forward to more discussion, thanks for participating everyone!<br><br>Logan</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 27, 2017 at 12:52 PM Paulo Faria <<a href="mailto:paulo@zewo.io">paulo@zewo.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr" class="gmail_msg">I'm with Brent a 100%. As discussed before in Open Swift, the embryo that lead to the Swift Server APIs Work Group, using a protocol for the HTTP request/response is not the best option because of the value type/reference type duality. People implementing an HTTP middleware, for example, would have to decide themselves which type semantics they're expecting the underlying implementation to provide. This means that code written with one semantics in mind would present bugs if used with an implementation that uses the other implementation. Of course we could restrict the protocol to reference types by making it a class protocol, but if we're doing that we might as well just go with classes. So the best solution is to go with concrete types. I prefer value type semantics, and to be honest, after reading the memory ownership manifesto, maybe move semantics would be the best option for HTTP request/response, but since we don't have it yet, I think we should go with value types for now.</p>
<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, Mar 27, 2017, 07:40 Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="gmail_msg" target="_blank">brent@architechies.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 23, 2017, at 2:51 AM, Logan Wright via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:</div><br class="m_-1578737702189333852m_5746091220769902759Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><div class="gmail_msg">Already we have multiple stakeholders in the group with very different ideas and use cases for the model, protocolizing this would allow us to focus on parsing and let frameworks choose how to model. By opting for generics constrained to our protocol internally, the compiler will inline the code and give us pretty good performance, in our generic constrained code, it was just as fast, or faster than it's model counterparts.</div><div class="gmail_msg"><br class="gmail_msg"></div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">Here's an example of a protocol required to parse a request<br class="gmail_msg"><br class="gmail_msg">```</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">protocol HTTPMessage {<br class="gmail_msg"> init(status: String, version: String, method: String, headers: [String: String], etc...<br class="gmail_msg">}<br class="gmail_msg">```<br class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">It doesn't need to be anything particularly complex, and we could include easily the inverse as well for the serializer. This could be a distinct protocol even for use cases we might not consider.</div></div></blockquote></div><div class="gmail_msg"><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Okay, but one of the major complaints I see in the GitHub thread is that some people want to use a reference type, and it seems like some people may want protocols so they can make that decision for themselves. I don't think that's going to work, though. If the protocol has any setters or mutating methods, then it will need to document whether it expects value or reference semantics; otherwise nobody will be able to know how to use those members properly.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">(Also, if that really is the entire `HTTPMessage` protocol—just an initializer—why not have users pass in a closure with that signature instead? They could easily pass `MyFramework.HTTPMessage.init` if they want, but they would have other choices too.)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">As for the performance aspect of value types, I don't quite see the concern. If we find that performance is a problem, we can switch to a copy-on-write implementation, where a public struct wraps a private class which actually contains the data; that should be exactly equivalent for ARC purposes. Choose value or reference based on the semantics you want; if the performance characteristics are wrong, you can then begin to optimize.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">
<span class="m_-1578737702189333852m_5746091220769902759Apple-style-span gmail_msg" style="border-collapse:separate;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;line-height:normal;border-spacing:0px"><div class="gmail_msg"><div style="font-size:12px" class="gmail_msg">-- </div><div style="font-size:12px" class="gmail_msg">Brent Royal-Gordon</div><div style="font-size:12px" class="gmail_msg">Architechies</div></div></span>
</div>
<br class="gmail_msg"></div></blockquote></div>
</blockquote></div>