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

Overriding SocketReactor::run() is not reasonably possible #4556

Open
ostkamp opened this issue May 13, 2024 · 1 comment
Open

Overriding SocketReactor::run() is not reasonably possible #4556

ostkamp opened this issue May 13, 2024 · 1 comment

Comments

@ostkamp
Copy link

ostkamp commented May 13, 2024

SocketReactor has a virtual run() method, see

virtual void run();

If it gets overridden by a run() method in a child class for extending its functionality, this child method has zero access to the required data of the base class (e.g. params provided to constructor, data added later through method calls etc.), since that data is completely private in base class. This also applies to several methods used in the original code of run() in the base class.

It is thus not possible to extend the functionality of the base class run() method.

To Reproduce
Create a child class inheriting from SocketReactor and add a run() method which overrides. Try to copy in the code from original run() method of the base class. It won´t compile because of accessing private members and methods. Try to instantiate an object just to ensure compilation is attempted.

Expected behavior
The currently private data of the base class SocketReactor should become protected so it can be accessed from overridden run() method in child class. This also applies to private methods used by the original run() method of the base class. Steps outlined in "To reproduce" should compile, link and work ok.

Logs
N/A

Screenshots
N/A

Please add relevant environment information:

  • Linux
  • Checked with POCO Version 1.13.3, most likely was in already earlier

Additional context
N/A

@ostkamp ostkamp added the bug label May 13, 2024
@aleks-f aleks-f added enhancement and removed bug labels May 14, 2024
@aleks-f aleks-f added this to the Release 1.14.0 milestone May 14, 2024
@aleks-f
Copy link
Member

aleks-f commented May 14, 2024

If you want access to the private members from child classes, send a PR which provides it through protected member functions; we will not make the member variables protected.

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

No branches or pull requests

2 participants