Functions file causes collisions if package is used more than once about assert

[schlessera]

Sorry for the spam in here, didn't realize that GitHub would pull in my change logs... :)

[shadowhand]

I disagree with this change, as this is not a failure in this package or in composer. The problem only exists when someone uses require 'vendor/autoload.php' instead of using require_once. This lowers the performance (a minuscule amount, I know) of every single request.

[shadowhand]

Which is to say, the problem should have been resolved by submitting patches to the offending WP plugins, instead of brute forcing a solution in this package.

[schlessera]

@shadowhand The problem is not due to WP plugins. This problem exists any time you have an app/framework that doesn't use Composer at the root level, and you still want to use Composer for whatever extension mechanism it uses. It is a limitation of PHP (that cannot autoload functions, only class-like elements), and the above patch just makes sure the assert library can still be used in such scenarios.

[schlessera]

Ah, btw, just wanted to state that require_once will not fix the above issue in many cases, as it does not work on basis of the class to load, but rather on the filepath to retrieve the class from. If you require_once the same file from two different locations, both will be loaded.

[shadowhand]

If you require_once the same file from two different locations, both will be loaded.

That's an incorrect statement. As per the docs:

The require_once statement is identical to require except PHP will check if the file has already been included, and if so, not include (require) it again.

[schlessera]

Yes, but it checks this by comparing the (normalized) absolute path. If you require the same file from two different locations on your filesystem/Phar/stream, require_once will not notice that these are the same.

That being said, Composer does not use require_once, but rather a standard require in its "files" autoloader: https://github.com/composer/composer/blob/master/src/Composer/Autoload/AutoloadGenerator.php#L715

[shadowhand]

I still don't understand the problem. Is this a problem with trying to combine composer and manual file loading?

[schlessera]

The problem is that, as soon as you use "procedural code" with Composer, it uses the "files" hack to simulate autoloading. However, this is no real autoloading (as it is not supported by PHP), so it behaves differently than normal autoloading.

And whereas you can freely combine Composer autoloaders and other autoloaders in whatever layouts and hierarchies as you see fit in a legacy application (meaning one you cannot just build from the ground up from one composer.json file), this all breaks with fatal errors if you do declarations in files that are loaded through the Composer "files" mechanism.

The above is an easy way to allow the beberlei/assert library to work under non-optimal conditions without breaking. This cannot be solved by the consuming code, because the problem is embedded in Composer's autoloader generator.

[shadowhand]

Still not making sense. If you're using composer everywhere, and you always use require_once __DIR__ . '/some/path/to/autoload.php'; will anything break? I can't see why it would.

[schlessera]

I'm specifically talking about use cases where you cannot use Composer everywhere. WordPress is one such example, but it's far from the only legacy PHP system out there that does not use Composer itself but can be extended.

As I said, if you're working under ideal conditions and just bootstrap your entire app/site from one composer.json file, this is a non-issue. But in that case, the above safeguards won't hurt you either.

[rquadling]

The !function_exists() is surely a requirement to stop attempting to duplicate the loading of functions for anyone using a polyfill. Every polyfill I've seen uses the same pattern.

[shadowhand]

The !function_exists(...) is used in polyfills to define functions in the global namespace while maintaining forward compatibility with newer PHP versions or extensions. Assert is not a polyfill.

[rquadling]

Hmm. True.