<font size=2 face="sans-serif">One factor is whether you consider the
version to be discrete values or a structured format for data - I'd argue
that we have a structured format due to the expectation that future versions
of the HTTP spec could arrive.</font>
<br>
<br><font size=2 face="sans-serif">Adding conformance to Hashable/Equatable
and CustomStringConvertible provides the operations, and whilst it may
look strange we could also provide convenience constants if it makes sense,
ie:</font>
<br><font size=2 face="sans-serif"> public static let http1_0
= HTTPVersion(major: 1, minor: 0)</font>
<br><font size=2 face="sans-serif"> public static let http1_1
= HTTPVersion(major: 1, minor: 1)</font>
<br><font size=2 face="sans-serif"> public static let http2_0
= HTTPVersion(major: 2, minor: 0)<br>
</font>
<br><font size=2 face="sans-serif">Having said that, there is slight additional
storage overhead for structs vs. enums, as a slight additional compare
cost.</font>
<br>
<br><font size=2 face="sans-serif">Chris</font>
<br>
<br><tt><font size=2>Michael Chiu <hatsuneyuji@icloud.com> wrote
on 14/06/2017 08:12:35:<br>
<br>
> From: Michael Chiu <hatsuneyuji@icloud.com></font></tt>
<br><tt><font size=2>> To: Rien <Rien@Balancingrock.nl></font></tt>
<br><tt><font size=2>> Cc: Chris Bailey <BAILEYC@uk.ibm.com>,
swift-server-dev@swift.org</font></tt>
<br><tt><font size=2>> Date: 14/06/2017 08:12</font></tt>
<br><tt><font size=2>> Subject: Re: [swift-server-dev] Convert HTTPVersion
to struct</font></tt>
<br><tt><font size=2>> <br>
> I think currently the http version is come from the http_parser <br>
> which has parsed the version string to number anyway. hence the <br>
> performance should be similar.<br>
> <br>
> I do see some advantage to use struct tho, for example comparing <br>
> only major version.<br>
> <br>
> Michael<br>
> <br>
> > On Jun 13, 2017, at 11:41 PM, Rien via swift-server-dev <swift-<br>
> server-dev@swift.org> wrote:<br>
> > <br>
> > The choices seem to be:<br>
> > <br>
> > 1) String<br>
> > 2) Enum<br>
> > 3) Tuple<br>
> > 4) Struct<br>
> > 5) Class<br>
> > <br>
> > 1) String<br>
> > Advantage: it is in fact an utf-8 string. No conversions needed.<br>
> > Disadvantage: It is mostly thought of as a number, thus the <br>
> abstraction does not match the type, very minor performance penalty
<br>
> in comparing. Illogical to add HTTP-version extensions to the type.<br>
> > <br>
> > 2) Enum<br>
> > Advantage: shortest possible representation (?), fastest compare
<br>
> (?), easy to use.<br>
> > Disadvantage: Needs converting to and from.<br>
> > <br>
> > 3) Tuple<br>
> > Advantage: Matches fairly wel with the abstraction.<br>
> > Disadvantage: Fairly complex conversion, adding members/operations<br>
> is non-intuitive, not very easy to use.<br>
> > <br>
> > 4) Struct<br>
> > Advantage: Matches fairly wel with the abstraction.<br>
> > Disadvantage: Fairly complex conversion. Not very easy to use
<br>
> without adding members/operations.<br>
> > <br>
> > 5) This was for completeness only, I would be very surprised
if <br>
> anybody would actually propose this… ;-)<br>
> > <br>
> > <br>
> > To me that leaves option 2 and 4.<br>
> > Advantage of 2 over 4:<br>
> > <br>
> > - I find the abstraction a better match. The difference between
1,<br>
> 1.1 and 2 is such that it makes little sense to be to differentiate
<br>
> based on the numerical values. It makes much more sense to <br>
> differentiate based on the “whole number”. AFAIIC they could just
as<br>
> easily have named the versions A, B, C etc. The numbers do not <br>
> convey any information as such.<br>
> > - Switch is easier and more intuitive to use.<br>
> > - Enums can have additional properties and operations similar
to struct.<br>
> > <br>
> > Advantage of 4 over 2:<br>
> > I don’t see any.<br>
> > <br>
> > Regards,<br>
> > Rien<br>
> > <br>
> > Site: </font></tt><a href=http://balancingrock.nl/><tt><font size=2>http://balancingrock.nl</font></tt></a><tt><font size=2><br>
> > Blog: </font></tt><a href=http://swiftrien.blogspot.com/><tt><font size=2>http://swiftrien.blogspot.com</font></tt></a><tt><font size=2><br>
> > Github: </font></tt><a href=http://github.com/Balancingrock><tt><font size=2>http://github.com/Balancingrock</font></tt></a><tt><font size=2><br>
> > Project: </font></tt><a href=http://swiftfire.nl/><tt><font size=2>http://swiftfire.nl</font></tt></a><tt><font size=2>
- An HTTP(S) web server framework in Swift<br>
> > <br>
> > <br>
> > <br>
> >> On 13 Jun 2017, at 22:44, Chris Bailey via swift-server-dev
<br>
> <swift-server-dev@swift.org> wrote:<br>
> >> <br>
> >> Based on our discussed approach of reviewing each of the
types in<br>
> the HTTP project, I've raised the following PR to convert <br>
> HTTPVersion from (Int, Int) to a struct based on Paulo's proposal:
<br>
> >> </font></tt><a href="https://github.com/swift-server/http/pull/6"><tt><font size=2>https://github.com/swift-server/http/pull/6</font></tt></a><tt><font size=2>
<br>
> >> <br>
> >> I've not yet added Hashable, Equatable and <br>
> CustomStringConvertible protocols - we can do that if we're happy
<br>
> with the change. <br>
> >> <br>
> >> Chris<br>
> >> Unless stated otherwise above:<br>
> >> IBM United Kingdom Limited - Registered in England and Wales
with<br>
> number 741598. <br>
> >> Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire PO6 3AU<br>
> >> _______________________________________________<br>
> >> swift-server-dev mailing list<br>
> >> swift-server-dev@swift.org<br>
> >> </font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><font size=2>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt><font size=2><br>
> > <br>
> > _______________________________________________<br>
> > swift-server-dev mailing list<br>
> > swift-server-dev@swift.org<br>
> > </font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><font size=2>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt><font size=2><br>
> <br>
</font></tt><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>