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

[Dan Appel]

Woah, that formatting got really messed up. Let me try again...



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 any, but I'm sure others can bring something interesting to
the table.




On Wed, Nov 23, 2016 at 1:07 PM Dan Appel <dan.appel00 at gmail.com> wrote:

> Hello everyone!
>
> I was unable to make the kick-off meeting for the HTTP sub-team, but I
> looked over the meeting 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
>
-- 
Dan Appel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161123/03e0fb07/attachment.html>