[swift-server-dev] Convert HTTPVersion to struct

[Rien]

> On 14 Jun 2017, at 11:13, Tanner Nelson <tanner at vapor.codes> wrote:
> 
> 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?
> 

+1

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 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