[swift-server-dev] [HTTP] Value vs Reference Types

[Dan Appel]

> Hello everyone!
> 
> I was unable to make the kick-off meeting for the HTTP sub-team, but I looked over themeeting notes(https://docs.google.com/document/d/1SWK0qBDi-9DeLJwHlcXcPU7h22JU-DWW8HTVuHbTQiw/edit)and found some topics that I think could use some more on-the-record discussion.
> 
> A few questions that I wanted to raise:
> 
> 1. Do we want to use concrete types or protocols for Request/Response?
> 2. If we use concrete types, do we want value or reference semantics?
> 3. When is it more convenient to have reference semantics?
> 4. Are there problems that can't be solved with value semantics?
> 
> I would like to avoid bike-shedding, and I think this can be done by providing real examples rather than just talking about the pros and cons.
> --
> Dan Appel
> 
> 
> 

My own responses:

>1. Do we want to use concrete types or protocols for Request/Response?

When working on Open Swift <https://github.com/open-swift>, this was a hot topic since we believed that it would be unsafe to have a protocol that would allow both value and reference types. We arrived upon the `{Request|Response}Representable` pattern which worked but was a bit of a mess. Because of this, I would prefer concrete Request/Response types.

>2. If we use concrete types, do we want value or reference semantics?

What I think makes this easier is that the "big four" have each taken a slightly different approach that can be used as a reference.
Zewo <https://github.com/Zewo/Zewo/blob/master/Modules/HTTP/Sources/HTTP/Message/Request.swift#L3> - struct, value semantics
Vapor <https://github.com/vapor/engine/blob/master/Sources/HTTP/Models/Request/Request.swift#L4> - closed class, reference semantics
Kitura <https://github.com/IBM-Swift/Kitura/blob/master/Sources/Kitura/RouterRequest.swift#L26> - closed class + has-a pattern, reference semantics
Perfect <https://github.com/PerfectlySoft/Perfect-HTTP/blob/master/Sources/HTTPRequest.swift#L25> - class protocol, reference semantics

Zewo is the outlier here, but I would like to note as a contributor to Zewo that we have not ran into situations where value semantics create an impassable roadblock. 

To me, it makes sense to pass them around as values since they don't have any logic of their own. Requests/Responses can't send themselves, they can only read and modified. It also gives me as a user more safety to pass them around since I know that they won't be modified implicitly.

Take the following pseudo-code as an example:

HTTPServer.onRequest { request in
    print(request.sourceIp)
    HTTPClient.send(request)
    print(request.sourceIp)

}

With reference semantics, there is no guarantee that sourceIp will be the same before and after sending off the request. After all, it could make sense for the HTTPClient to modify the sourceIp before sending off the request. This of course a contrived example, but the point stands.

Anyway, I think it would be great if we could have people talk about their own experiences.

>3. When is it more convenient to have reference semantics?

In the middleware chain architecture that we decided on in Zewo (the other ones have something similar), it can be convenient to modify requests in the responder and have that reflect in the middleware. I think this problem is best solved with `inout` parameters rather than reference types, but that is my personal opinion.

>4. Are there problems that can't be solved with value semantics?

I haven't found one that we can't solve, but I'm sure others can bring something interesting to the table.

--

Dan Appel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161123/aea37985/attachment.html>