[swift-server-dev] Convert HTTPVersion to struct

Tanner Nelson tanner at vapor.codes
Wed Jun 14 04:13:39 CDT 2017


I approved the changes in Chris's PR swift-server/http#6, I think moving
away from typealias wherever possible is a great idea. IMO typealiases
really only make sense for protocol composition.

On an unrelated note, I'm considering submitting a PR that would move the
HTTP models into a module named `HTTP`. This would name space things like
`HTTPVersion` to `HTTP.Version` (usable as just `Version` when no
ambiguities exist). I think this would make the package more concise and
feel less like Obj-C.
Any arguments against name spacing?

On Wed, Jun 14, 2017 at 8:13 AM Michael Chiu via swift-server-dev <
swift-server-dev at swift.org> wrote:

> I think currently the http version is come from the http_parser which has
> parsed the version string to number anyway. hence the performance should be
> similar.
>
> I do see some advantage to use struct tho, for example comparing only
> major version.
>
> Michael
>
> > On Jun 13, 2017, at 11:41 PM, Rien via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >
> > The choices seem to be:
> >
> > 1) String
> > 2) Enum
> > 3) Tuple
> > 4) Struct
> > 5) Class
> >
> > 1) String
> > Advantage: it is in fact an utf-8 string. No conversions needed.
> > Disadvantage: It is mostly thought of as a number, thus the abstraction
> does not match the type, very minor performance penalty in comparing.
> Illogical to add HTTP-version extensions to the type.
> >
> > 2) Enum
> > Advantage: shortest possible representation (?), fastest compare (?),
> easy to use.
> > Disadvantage: Needs converting to and from.
> >
> > 3) Tuple
> > Advantage: Matches fairly wel with the abstraction.
> > Disadvantage: Fairly complex conversion, adding members/operations is
> non-intuitive, not very easy to use.
> >
> > 4) Struct
> > Advantage: Matches fairly wel with the abstraction.
> > Disadvantage: Fairly complex conversion. Not very easy to use without
> adding members/operations.
> >
> > 5) This was for completeness only, I would be very surprised if anybody
> would actually propose this… ;-)
> >
> >
> > To me that leaves option 2 and 4.
> > Advantage of 2 over 4:
> >
> > - I find the abstraction a better match. The difference between 1, 1.1
> and 2 is such that it makes little sense to be to differentiate based on
> the numerical values. It makes much more sense to differentiate based on
> the “whole number”. AFAIIC they could just as easily have named the
> versions A, B, C etc. The numbers do not convey any information as such.
> > - Switch is easier and more intuitive to use.
> > - Enums can have additional properties and operations similar to struct.
> >
> > Advantage of 4 over 2:
> > I don’t see any.
> >
> > Regards,
> > Rien
> >
> > Site: http://balancingrock.nl
> > Blog: http://swiftrien.blogspot.com
> > Github: http://github.com/Balancingrock
> > Project: http://swiftfire.nl - An HTTP(S) web server framework in Swift
> >
> >
> >
> >> On 13 Jun 2017, at 22:44, Chris Bailey via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> >>
> >> Based on our discussed approach of reviewing each of the types in the
> HTTP project, I've raised the following PR to convert HTTPVersion from
> (Int, Int) to a struct based on Paulo's proposal:
> >>       https://github.com/swift-server/http/pull/6
> >>
> >> I've not yet added Hashable, Equatable and CustomStringConvertible
> protocols - we can do that if we're happy with the change.
> >>
> >> Chris
> >> Unless stated otherwise above:
> >> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598.
> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >> _______________________________________________
> >> swift-server-dev mailing list
> >> swift-server-dev at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-server-dev
> >
> > _______________________________________________
> > swift-server-dev mailing list
> > swift-server-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-server-dev
>
> _______________________________________________
> 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/20170614/53a0db73/attachment.html>


More information about the swift-server-dev mailing list