[swift-server-dev] Convert HTTPVersion to struct

[Rien]

> 
> On 14 Jun 2017, at 13:46, Tanner Nelson <tanner at vapor.codes> wrote:
> 
> Requiring a new version to support new features and having existing code be compatible with a new version are two different things. 
> 

Yes! thank you.
Lets go for the struct.

I was sitting too much in my own little world and not thinking as an API developer.

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 12:44 Rien <Rien at balancingrock.nl> wrote:
> 
> > On 14 Jun 2017, at 13:29, Tanner Nelson <tanner at vapor.codes> wrote:
> >
> > Unless there is a need to be able to exhaustively switch over all supported HTTP versions, using an enum seems overly restrictive. Especially when considering that adding or removing cases from enums is a breaking change (requires a major version bump).
> 
> I presume that supporting a new HTTP version will always require a major version bump.
> 
> Rien.
> 
> 
> > As authors of a general purpose HTTP package, we should be avoiding unnecessary restrictions wherever possible.
> >
> > As an aside, Go also uses two integers to represent major and minor. https://golang.org/pkg/net/http/#Request
> > On Wed, Jun 14, 2017 at 11:38 Rien via swift-server-dev <swift-server-dev at swift.org> wrote:
> >
> > > On 14 Jun 2017, at 12:11, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> > >
> > > On 14. Jun 2017, at 11:36, Rien via swift-server-dev <swift-server-dev at swift.org> wrote:
> > >>> On 14 Jun 2017, at 11:14, Chris Bailey <BAILEYC at uk.ibm.com> wrote:
> > >>>
> > >>> 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.
> > >>
> > >> But do you want your code littered with numerical tests or conceptual tests?
> > >> Suppose a new version of HTTP does arrive, do you really want to manually walk through the code and find all tests on the numerical values?
> > >> Or would it be easier to use switch statements on an enum and have all missing cases pointed out to you?
> > >
> > > This is actually a argument *for* using numbers. When using an enum in an API makes the same break every time you change it. And that is killer for a an API representing a living protocol like HTTP.
> > >
> > > Also in proper source you would check for: `if major >= 2`, not `==`, another advantage of using version _numbers_.
> > >
> > > In the context of HTTPVersion
> >
> > Precisely. I am making the argument for enum’s only for the HTTPVersion since it is such a unique feature.
> >
> >
> > > I think there shouldn’t be too much discussion though, for two reasons:
> > > - If we get HTTP/3.x, we almost certainly have a new API revision.
> >
> > Absolutely.
> >
> > > - The HTTP version should only matter for logging purposes. The differences in capabilities
> > >  should be handled by the implementation (e.g. keep alive vs not, multiplexing or not, etc).
> >
> > Agreed, which is why the decision should be made carefully. An API developer usually sees things differently from an API user. Conceptually a version number is just a tag. It does not represent a numerical value. Which makes testing for numerical values error prone, which leads to your following point:
> >
> > >  In other words, you should never have to check for the versions, but rather features.
> >
> > Again, fully agreed. But which I interpret as an argument in favour of enums...
> >
> > Rien.
> >
> > >
> > > hh
> > >
> > > _______________________________________________
> > > 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
>