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

[Scoper] Whitelist @internal symbols #347

Closed
sebastianbergmann opened this issue Jul 7, 2019 · 3 comments
Closed

[Scoper] Whitelist @internal symbols #347

sebastianbergmann opened this issue Jul 7, 2019 · 3 comments

Comments

@sebastianbergmann
Copy link
Contributor

See sebastianbergmann/phpunit#3750.

@theofidry
Copy link
Member

I'll have to add a similar autoloading mechanism as https://github.com/theseer/Autoload to HumbugBox then, as this feature would otherwise completely break the regular autoloading.

@theofidry
Copy link
Member

I am not 100% sure how this should be handled. I think the best way would, when dealing with a class, interface or trait declaration, check its comment and register it to the whitelist if has @internal. This way implementing the autoloading mechanism https://github.com/theseer/Autoload is not necessary since it won't break autoloading. A new config setting should be added however

@theofidry theofidry changed the title Do not prefix classes/interfaces/traits that are annotated with @internal [Scoper] Whitelist @internal symbols Sep 5, 2020
@theofidry theofidry added this to the 1.0.0 milestone Sep 5, 2020
@theofidry theofidry removed this from the 1.0.0 milestone Nov 13, 2022
@theofidry
Copy link
Member

Revisiting the issue, I do not think this is worth pursuing anymore.

The problem I can see with this approach, is that by default, symbols are not exposed. So making @internal symbols not exposed despite being configured as exposed (via a namespace for example), means there will never be a way to expose an internal symbol.

Whilst the above can make sense in some situations, I see how it could 1. be a surprising behaviour and and 2. not be desired in some situations.

That being said, the configuration changed a lot since the issue was posted. There is now several exclude/expose strategies via either names and/or regexes.

Alternative an approach akin to the one done for Wordpress plugins can be adopted which is to have a tool checking the codebase and collecting the internal symbols, and then pass this result to PHP-Scoper (whether those symbols are collected before-hand or when loading the config is at the discretion of the user).

If it proves useful, this could be made into either a class exposed to the config, or via a command which could dump the result into a file and load this in the scoper.inc.php.

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