auryn
auryn copied to clipboard
rdlowrey
Dev into master
Everything should be just fixes, unless I've mucked up.
At Levi's suggestion, PHP 7.2.0 is the new minimum version as that is the version supported by Ubuntu LTS.
Looks like something broke 7.2 and 7.3 compatibility, but I personally don't think they should be supported anymore, regardless of if they are part of a LTS distribution. 7.4 is the oldest supported (security fixes only) version of PHP at this time.
Looks like something broke 7.2 and 7.3 compatibility,
Only the benchmark. I've split that off into a separate job.
Just stopped by to say thank you for supporting this. Still using auryn in dozens of productions and still loving it.
Considering this repository is not getting too much love lately, does anyone have any concerns at this point in time in making all private methods protected to allow extending it? I have a couple of modifications on my mind that would require that, otherwise it's copy-pasting the entire \Auryn\Injector class.
Things I have in mind are Attribute support (One for sharing and one for delegating object instantiations) and the other one being adding additional debug information. With that said I'm pretty sure this is not something that would see it's way to master branch here considering the pretty conservative approach.
I'm sure there's many people who would come up with some additional ideas that would not get broken on updates of this repository.
With that said I'm pretty sure this is not something that would see it's way to master branch here considering the pretty conservative approach.
Would there be any downside in making the methods be protected by default?
I mean, other than possibly people asking for more changes later.
With the BC break mentioned above and just the sheer size of this change set, maybe it's time to just call it 2.0-beta just to get it merged? I personally have no issue with changing some methods to protected, especially if it means easily pluggable Attribute support.
With that said I'm pretty sure this is not something that would see it's way to master branch here considering the pretty conservative approach.
Would there be any downside in making the methods be protected by default?
I mean, other than possibly people asking for more changes later.
I would say no. From the "your average developer" perspective, if you can't do something you go for a dirty workaround. Considering the change from private to protected is not related to the userland code (as in using Auryn for it's defined functionality in public methods), but rather for extension purposes - to improve the library by additional functionality, I don't see any reason not to.
Just a simple and quite popular example in the issues section is the PSR-11 container interop compatibility, which to my mind is a no-go to be in this library because of the service locator as mentioned multiple times, but let's drop down to earth - this is often a requirements for integrating other packages. Then you end up with 2 of them, which reveals a question of "why 2, when we can have one (not auryn) as the code is already polluted with service location. But where am I leading is this: https://github.com/elazar/auryn-container-interop - probably most well known and used extension, but looking at the code it's "hacky" because of reusing what is meant to be an array of class strings as keys gets reused for arbitrary strings. As it's a service locator, I bet it should be share-by-default in 99% of the cases as well.
I mean, a much better implementation would be possible.
Agree with what @baohx2000 said, it can be a v2, even with BC breaks. This might even be a better approach as it will be easier to maintain this.
Hello, I'm about to start a new PHP project using auryn. Having seen the amount of changes of this pull request and the possibility that some of them might break compatibility, do you recommend using this version instead of the stable (master) one even if it hasn't been merged yet? Apart from bug fixes and modern php support, are there changes in funcionality? Thank you
