Replace global DI library functions with corresponding objects for PRS-4 compliance

[phpfui]

This PR makes the library fully PSR-4 compliant.

The php-di/php-di library supports global functions for various setup configurations. The problem is global functions are not PRS-4 compliant, so using a super fast and minimal memory footprint autoloader fails.

The solution is simple, use the corresponding classes called by the global functions. It turns out the php-di library does not use these global functions, and it is considered bad form to use global functions, as they are not PSR-4 compliant. Guzzle has recently depreciated global functions for example.

[zbateson]

Ooh, interesting... yeah sure, happy to change that so different autoloaders don't complain.

Want me to do a quick 3.0.2 for it right away? Or do you want to have a look around and see if there's anything else you might want to update in the next week or so?

[phpfui]

I am good for now. I could not get my hosting service to work as a test for me, but it is in prod now. So far, no issues.

…

On Wed, May 1, 2024, 12:49 PM Zaahid Bateson ***@***.***> wrote: Ooh, interesting... yeah sure, happy to change that so different autoloaders don't complain. Want me to do a quick 3.0.2 for it right away? Or do you want to have a look around and see if there's anything else you might want to update in the next week or so? — Reply to this email directly, view it on GitHub <#238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABYW6SZ4HJB6BUERYT656Y3ZAEMJHAVCNFSM6AAAAABHCAGZ2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYG42TIMBUGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mnapoli]

Hi, I'm the author of php-di. I'm curious what the problem was.

PHP-DI's functions are not global, they are namespaced, like any other class. It's perfectly valid and normal PHP code. This is unrelated to PSR-4 which only focuses on classes, so it's neither compliant nor "noncompliant", it's like saying using JavaScript in the browser is noncompliant with PSR-4.

Guzzle has recently depreciated global functions for example.

They did because of conflicts with a potential global install of guzzle. PHP-DI doesn't have this problem because PHP-DI functions are loaded only once.

So that's why I'm curious what is the root problem, and if there's anything I can do to help or should adjust in PHP-DI.

[phpfui]

@mnapoli The issue has to do with not using the Composer generated autoloader, which is consumes large chunks of memory and is slow to load (reading in the huge mapping into memory on every page call). Your library is fine if you want to use the composer autoloader, but I know many projects concerned about memory usage and speed, so they use a file path based autoloader. My app does not need to parse emails on every invocation of a page, and I don't want to load your stand alone functions each time. Since PHP is an interpreted language, runtime performance needs to be optimized where ever possible. If PHP were a compiled language, this would not be an issue.

As I remember, the solution was simple, just use the static member functions these functions all directly. While they may be namespaced, and I am sure you did this for convenience purposes, the static member functions are really not that much more difficult to use.

If you did not have static member functions, I would have submitted a PR for you to fix the problem, but your library is fine as is, just don't use the stand alone functions and everything is good.

And thanks for being a concerned open source contributor!

[mnapoli]

Got it, thanks for explaining! TIL that some projects don't use Composer 👍