Start to deprecate HTTPServerOption

[wilzbach]

A hack to start triggering deprecation for HTTPServerOption.

I assumed that if we go this way, #1946 would have been incorporated.

[WebFreak001]

adding lowercased deprecated symbols seems useless, otherwise the "It is done lazy." message could be adjusted and then it looks good

[WebFreak001]

Maybe change these messages to this is done lazily now

[WebFreak001]

Plus this whole block of new lower case variants shouldn't exist at all because the upper case variants are being deprecated

[WebFreak001]

There is a space too much here

[WebFreak001]

Maybe add a TODO comment that this should be turned back to an enum once the deprecated symbols are removed

[s-ludwig]

I thought about going this route too, but the fact that this loses type safety combined with the risk that this may remain a permanent installation (i.e. never reaches a state where there are no deprecated values) also lead me to abandon the idea. However, I think what would reasonably limit this risk is to define an additional enum HTTPServerOptionImpl { ... } that contains only the values that are still relevant and then convert the HTTPServerOption.x field to HTTPServerOptionImpl.

[thaven]

That made me think.... Maybe we should go the opposite direction. Leave HTTPServerOption as an enum, and add a second enum for the deprecated members. Those deprecated members appear in HTTPServerOption itself as forwards to the new enum, which is to be marked deprecated.

So it looks like this:

enum HTTPServerOption {
    none = 0,
    None = HTTPServerOptionDepr.None,
    //....
}

deprecated enum HTTPServerOptionDepr {
    None = HTTPServerOption.none
}

Just popped intomy mind. Didn't test it.

[s-ludwig]

I'd guess that that would warn at the None = HTTPServerOption.none line instead of in user code, but it would be worth a try.

[s-ludwig]

Surprisingly, if the deprecated enum is declared after the regular one, there is no deprecation warning at all. But if they are reversed, the warning indeed happens within HTTPServerOption, unfortunately.

[wilzbach]

Plus this whole block of new lower case variants shouldn't exist at all because the upper case variants are being deprecated

@WebFreak001 there are no new upper case variants? Did you mean that the deprecated messages on the upper case variants are superfluous because they have been deprecated for a very long time? The problem here is that the user has never seen a deprecation message.

However, I think what would reasonably limit this risk is to define an additional enum HTTPServerOptionImpl { ... } that contains only the values that are still relevant and then convert the HTTPServerOption.x field to HTTPServerOptionImpl.

Did you mean this like it's done now?

I thought about going this route too, but the fact that this loses type safety combined with the risk that this may remain a permanent installation (i.e. never reaches a state where there are no deprecated values) also lead me to abandon the idea.

Hmm another idea about moving forward would be to go with a new concept as we only have errorStackTraces and reusePort as options left. The simplest one would be to create sth. like:

enum HTTPServerConfig {
	none                      = 0,
	errorStackTraces          = 1<<7,
	reusePort                 = 1<<8,
	defaults = () { debug return HTTPServerConfig.errorStackTraces; else return HTTPServerConfig.none; } (),

}

However, I'm not sure whether we can safely use HTTPServerConfig directly or whether we would have to do sth. like this:

        deprecated("Please use .config and HTTPServerConfig")
	HTTPServerOption options = HTTPServerOption.defaults;
	HTTPServerConfig config = HTTPServerConfig.defaults;

[WebFreak001]

How about making breaking changes and waiting for 0.9.0 to merge this then? It should also like drop all other deprecated stuff

[s-ludwig]

@wilzbach I think the current approach should work! It was mainly just the int field that was the issue. Hopefully the current push for enum attributes will lead somewhere, then there is also a clear path back to a plain enum type.

@WebFreak001 Things are getting deprecated and removed all the time, because that has been the only reasonable development mode until now. Instead of a 0.9.x branch, the plan is to break out individual sub packages into separate repositories and start with a 1.x.x version numbering there. The API will then at the same time be refactored with all the experience that has been built up so far, to ensure that the 1x branch can live as long as possible.

I'll wait with the merge after 0.8.2 has been released (I'll announce the RC in the coming days and then tag the release a week later).