New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start to deprecate HTTPServerOption #1947

Merged
merged 1 commit into from Dec 11, 2017

Conversation

Projects
None yet
4 participants
@wilzbach
Contributor

wilzbach commented Oct 10, 2017

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

parseCookies = 1<<5,
struct HTTPServerOption {
static enum none = 0;
deprecated("It is done lazy.")

This comment has been minimized.

@WebFreak001

WebFreak001 Oct 31, 2017

Contributor

Maybe change these messages to this is done lazily now

This comment has been minimized.

@WebFreak001

WebFreak001 Oct 31, 2017

Contributor

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

deprecated("It is done lazy.")
static enum ParseCookies = none;
int x;

This comment has been minimized.

@WebFreak001

WebFreak001 Oct 31, 2017

Contributor

There is a space too much here

parseMultiPartBody = 1<<4,
/// Deprecated: Fills the `.cookies` field in the request
parseCookies = 1<<5,
struct HTTPServerOption {

This comment has been minimized.

@WebFreak001

WebFreak001 Oct 31, 2017

Contributor

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

@s-ludwig

This comment has been minimized.

Member

s-ludwig commented Nov 5, 2017

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

This comment has been minimized.

Contributor

thaven commented Nov 5, 2017

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

This comment has been minimized.

Member

s-ludwig commented Nov 5, 2017

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

This comment has been minimized.

Member

s-ludwig commented Nov 5, 2017

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

This comment has been minimized.

Contributor

wilzbach commented Nov 30, 2017

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

This comment has been minimized.

Contributor

WebFreak001 commented Nov 30, 2017

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

This comment has been minimized.

Member

s-ludwig commented Nov 30, 2017

@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).

@s-ludwig s-ludwig merged commit dc634d8 into vibe-d:master Dec 11, 2017

3 of 4 checks passed

codecov/patch 0% of diff hit (target 60.209%)
Details
codecov/project 61.553% (+1.344%) compared to e424042
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment