Handle custom string manipulations about php-scoper HOT 5 CLOSED

I think we would be better off trying to patch PhpParser rather

from php-scoper.

Just for reference, the second example can be resolved with (23 being uniqid() string length):

PhpParser\NodeAbstract::getType():

public function getType()
{
    return strtr(substr(rtrim(get_class($this), '_'), 15+23), '\\', '_');
}

No further errors thereafter.

As regards patching, we can patch this directly (if that's what you mean, via makefile), but the prefix is not static so we still need a way to advise the patching op of what the prefix is, so patching needs to be done either during scoping (which the issue title suggests) or post-scoping when we can signal or retrieve it - perhaps even just dump the prefix to a simple file for reading instead of searching for it.

from php-scoper.

I meant to do a PR on PhpParser to update the code to be more PHPScoper friendly instead. If it doesn't add complexity and works well, I don't see why it wouldn't be accepted.

So essentially, we need a facility to apply simple patches to files

Eventually we'll be forced to apply this kind of patch, but I would prefer to try to delay this as much as possible.

Two possible solutions though:

• Via the Node traverser (the simplest solution I think but the performance impact might be non-negligeable
• Analyse the file content and change it with a preg_replace() or something

from php-scoper.

I'm more worried about other users being forced to, so I'm not sure it needs to be delayed. At a minimum, we can easily document the problem and solutions with other tools, e.g. patch.

I would go with keeping it relatively simple for downstream users - an array of filenames, search strings and replacement strings, a decorated scoper to apply them, and an input option to import them from a file format. Then mention the existence of options that can alternatively be used post-scoping in the README.

from php-scoper.

Yeah we'll definitely need an extension point for that

from php-scoper.