-
Notifications
You must be signed in to change notification settings - Fork 0
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
Initial implementation #1
base: develop
Are you sure you want to change the base?
Conversation
mecha
commented
Mar 16, 2021
- Add analysis tools
- Add manipulation tools
- Add graphing tools
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Superb. Not much more I can say. Can I merge this?
<configuration_option name="xdebug.remote_host" value="host.docker.internal" /> | ||
<configuration_option name="xdebug.remote_host" value="172.17.0.1" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK it should be host.docker.internal
, which is mapped to whatever IP via the docker-compose.yml
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
host.docker.internal
is Windows-specific, while AFAIK 172.17.0.1
is cross-platform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
host.docker.internal
is Windows specific with what Docker does automatically. But in php-project
setup we simply map the configured IP to hosts.docker.internal
, and so it will exist either way. If you can find where 172.17.0.1
is being documented to be a cross-platform way to access the host, I can put it into .env.example
, and it should work for everyone 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's continue this discussion in a more appropriate channel.
* @param array<callable|ServiceInterface> $factories The list of factories to analyze. | ||
* @param array<callable|ServiceInterface> $extensions The list of extensions to analyze. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can these be iterable
instead of array
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure. It's been a while since I wrote this. I'll get back to you on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They can't be iterable
because the desired type is, in actuality, array<string, callable|ServiceInterface>
.
Update: I have a ton of unpushed and uncommitted code in my local copy. Most of it has to do with the addition of a graph traverser, and rewrites of the existing analyzers to implement the visitor interface. The traverser would be very beneficial change for projects with larger service graphs, since the traverser only iterates the graph once whereas the current design has each analyzer iterate the graph for its own consumption. |