Skip to content
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

MessageEvent constructors without connection information #22

Open
dirk-thomas opened this issue Feb 14, 2014 · 5 comments
Open

MessageEvent constructors without connection information #22

dirk-thomas opened this issue Feb 14, 2014 · 5 comments
Labels
Milestone

Comments

@dirk-thomas
Copy link
Member

The MessageEvent constructors not receiving connections header are "evil". I tried to remove them in #21 before but could not get rid of all code which uses it (therefore they have been reintroduced).

But in two cases that already backfired. Two code parts which worked before behaved wrong (silently having empty connection header) which was difficult to spot:

In both cases with the "evil" MessageEvent constructors present the code compiles but does not work correctly due to the missing connection info. When the two constructors are commented out the code fails to build. I worked around that with the two commits referenced above.

But this should not be necessary. I think the templated functions for subscribing to topics should deal with this problem and avoid the usage of the "evil" constructors without requiring the commited hacks.

@dirk-thomas
Copy link
Member Author

@esteve @tfoote @wjwwood Any support is highly appreciated. We should be able to remove these "evil" constructors and also not require the above referenced commits (aka. hacks).

@dirk-thomas dirk-thomas added this to the Untargeted milestone Feb 22, 2016
@kalectro
Copy link
Contributor

Is anybody still working on this?

@dirk-thomas
Copy link
Member Author

The milestone descriptions says:

It is unlikely that the maintainers will have time to address these issues. Please provide pull requests if you want these issues to be addressed.

@cwecht
Copy link
Contributor

cwecht commented Feb 28, 2019

What about deprecating these constructors? This would make it easier to spot the places, where they are used without breaking any code all of a sudden.

@peci1
Copy link
Collaborator

peci1 commented Jun 6, 2023

What about deprecating these constructors?

I don't think that's possible in an already released distro. Some packages take warnings as build errors, so we can't add any.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants