[swift-server-dev] Convert HTTPVersion to struct

[Michael Chiu]

This automatically include all future version without modify any existing code.

extension HTTPVersion {
    public func > (lhs: HTTPVersion, rhs: HTTPVersion) -> Bool
    {
         return lhs.major > rhs.major ? true : (lhs.minor > rhs.minor)
    }

    public static var minimumVersionSupportsMulitpleDomain: HTTPVersion {
        return HTTPVersion(1,1)
    }

    var isMulitpleDomainCapable: Bool {
        return self > HTTPVersion.minimumVersionSupportsMulitpleDomain
    }
}

Cheers,
Michael
> On Jun 14, 2017, at 2:30 AM, Rien <Rien at Balancingrock.nl> wrote:
> 
> 
>> On 14 Jun 2017, at 09:12, Michael Chiu <hatsuneyuji at icloud.com <mailto:hatsuneyuji at icloud.com>> 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.
> 
> That is likely, but imo the HTTP API should be judged on its own merits.
> 
> 
>> 
>> I do see some advantage to use struct tho, for example comparing only major version.
> 
> 
> That is where I don’t see a real world advantage. Theoretically you are correct, but in a real world example?, do you have an example where this is indeed useful?
> Given the limited range of useful versions numbers (only 3!) I just don’t see it.
> 
> I realize that this reaches into preferred programming techniques, but I like to use capability test on the type.
> I.e. I would write
> 
> enum HttpVersion { case http1_0, http1_1, http2_0 }
> 
> extension HttpVersion {
> 	var isMultipleDomainCapable: Bool {
> 		switch self {
> 		case .http1_0: return false
> 		case .http1_1: return true
> 		case .http2_0: return true
> 		}
> 	}
> }
> 
> if version.isMultipleDomainCapable {	}
> 
> instead of:
> 
> struct HttpVersion {
> 	let major: Int
> 	let minor: Int
> 
> 	static func == ...
> }
> 
> if (version == HttpVersion(1, 1) || (version == HttpVersion(2, 0)) {
> 	// supports multiple domains
> }
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl <http://balancingrock.nl/>
> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/>
> Github: http://github.com/Balancingrock <http://github.com/Balancingrock>
> Project: http://swiftfire.nl <http://swiftfire.nl/> - An HTTP(S) web server framework in Swift
> 
>> 
>> Michael
>> 
>>> On Jun 13, 2017, at 11:41 PM, Rien via swift-server-dev <swift-server-dev at swift.org <mailto: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 <http://balancingrock.nl/>
>>> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/>
>>> Github: http://github.com/Balancingrock <http://github.com/Balancingrock>
>>> Project: http://swiftfire.nl <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 <mailto: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 <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 <mailto: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 <mailto: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/877c98c0/attachment.html>