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

Dev into master #198

Open
wants to merge 68 commits into
base: master
Choose a base branch
from
Open

Dev into master #198

wants to merge 68 commits into from

Conversation

Danack
Copy link
Collaborator

@Danack Danack commented Apr 20, 2023

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.

martin-hughes and others added 30 commits December 9, 2022 17:05
… run on, as the PHP exception message changed.
@baohx2000
Copy link
Contributor

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.

Copy link
Contributor

@baohx2000 baohx2000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oof, that was a chonky pr.

@Danack
Copy link
Collaborator Author

Danack commented May 23, 2023

Looks like something broke 7.2 and 7.3 compatibility,

Only the benchmark. I've split that off into a separate job.

Comment on lines +13 to +16




Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is about 4 blank lines too many 😆

Copy link
Collaborator

@morrisonlevi morrisonlevi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have not reviewed the whole thing, but as a generalization, it looks good to me.

I want affirm that I think for a low-maintenance project like Auryn, having wide PHP version support is a virtue, not a hindrance. Thank you for supporting PHP 7.2.

@vlakarados
Copy link
Contributor

Just stopped by to say thank you for supporting this. Still using auryn in dozens of productions and still loving it.

ini-values: memory_limit=-1

- name: "Add PHPUnit matcher"
run: echo "::add-matcher::${{ runner.tool_cache }}/phpunit.json"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this do?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guessing here, but since we execute simple-phpunit instead of running phpunit directly, GH actions doesn't know how to map errors back to code to show properly in the action results. This fixes that by referring to the gh-action built-in mapping configuration for phpunit. https://fusectore.dev/2021/11/19/github-action-problem-matchers.html

- name: "Add PHPUnit matcher"
run: echo "::add-matcher::${{ runner.tool_cache }}/phpunit.json"

- run: composer install
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should probably be a name here, too?


simple-phpunit accepts PHPUnit commandline options and passes them through to PHPUnit e.g. `php php vendor/bin/simple-phpunit --group wip` to only run the tests tagged as being part of group 'wip'.

#### Running benchamarks
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#### Running benchamarks
#### Running benchmarks

Comment on lines +31 to +32
"friendsofphp/php-cs-fixer" : "3.3.1",
"phpbench/phpbench": "1.1.1",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want fixed versions here or ^ as well?

@@ -52,7 +52,7 @@ public function getCtorParams($class)
return $reflectedCtorParams;
}

public function getParamTypeHint(\ReflectionFunctionAbstract $function, \ReflectionParameter $param)
public function getParamType(\ReflectionFunctionAbstract $function, \ReflectionParameter $param)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a BC break.

Comment on lines +164 to +165


Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

@@ -40,7 +40,7 @@ public function getCtorParams($class);
* @param \ReflectionFunctionAbstract $function
* @param \ReflectionParameter $param
*/
public function getParamTypeHint(\ReflectionFunctionAbstract $function, \ReflectionParameter $param);
public function getParamType(\ReflectionFunctionAbstract $function, \ReflectionParameter $param);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a BC break.

{
$this->expectException(\Auryn\InjectionException::class);
// TODO - why does this message end with double-colon?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still an open TODO?

*/
public function testCustomDefinitionNotPassedThrough()
{
$injector = new Injector();
$injector->share('Auryn\Test\DependencyWithDefinedParam');

$this->expectException(\Auryn\InjectionException::class);
// TODO - why does this message end with double-colon?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still an open TODO?

@@ -2,7 +2,7 @@

namespace Auryn\Test;

class NoTypehintNoDefaultConstructorVariadicClass
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file should likely be renamed if we drop 5.6 support.

@vlakarados
Copy link
Contributor

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.

@Danack
Copy link
Collaborator Author

Danack commented Aug 27, 2023

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.

@baohx2000
Copy link
Contributor

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.

@vlakarados
Copy link
Contributor

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.

@nevez
Copy link

nevez commented Sep 7, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants