Interesting project, writing a useful PHP extension is an every web developer's dream.
However, the licence choice is weird. It's really asking to be MIT. Any company bigger than 2 people pays attention to that. Most web projects are proprietary. GPL‑v3-or-later is not appropriate for proprietary/closed-source.
Also, the README is lacking a nicely looking comparison chart, motivating people why they should use your project instead of just running grep in shell_exec. I'm very unlikely to run the benchmarking scripts myself. You have to convince me why your project is better than the established industry practice.
I made this as a joke with AI in about two hours because I kept seeing this pattern where code bases were grepping for classes because it was faster than anything else available to PHP userspace.
This is a runtime extension so it doesn't preclude you from using it as it would not be considered part of your proprietary code. Similar to how running grep through shell_exec is not the same as incorporating GPL code in your code. I suppose that is a matter of philosophical and legal opinion but I believe my interpretation is the de facto reality.
As for benchmarks there is a thing in the docs folder talking about that. I spend some time on it. The tldr is the PHP runtime is slower to startup so the overall slowness for PHP was 20% slower compared to the grep CLI but that's an apples to oranges comparison because if you already have a php thread running doing an extra ggrep call in userspace is going to be faster then grep because the binary doesn't need time to load into memory.
I just wanted to throw this code out there in case it's useful to anyone but I was considering write a new one for ripgrep or ag because they are both faster than GNU/Grep.
Interesting project, writing a useful PHP extension is an every web developer's dream.
However, the licence choice is weird. It's really asking to be MIT. Any company bigger than 2 people pays attention to that. Most web projects are proprietary. GPL‑v3-or-later is not appropriate for proprietary/closed-source.
Also, the README is lacking a nicely looking comparison chart, motivating people why they should use your project instead of just running grep in shell_exec. I'm very unlikely to run the benchmarking scripts myself. You have to convince me why your project is better than the established industry practice.
> GPL‑v3-or-later is not appropriate for proprietary/closed-source.
Perhaps that's the intent of the author. Not everyone is a fan of allowing companies to use your project for their closed source, proprietary garbage.
It's refreshing to see a project that isn't MIT.
The plugin directly adapts code from GNU Grep, so they MUST release it under the GPL, as far as I understand.
Thank you for your thoughts.
I made this as a joke with AI in about two hours because I kept seeing this pattern where code bases were grepping for classes because it was faster than anything else available to PHP userspace.
This is a runtime extension so it doesn't preclude you from using it as it would not be considered part of your proprietary code. Similar to how running grep through shell_exec is not the same as incorporating GPL code in your code. I suppose that is a matter of philosophical and legal opinion but I believe my interpretation is the de facto reality.
As for benchmarks there is a thing in the docs folder talking about that. I spend some time on it. The tldr is the PHP runtime is slower to startup so the overall slowness for PHP was 20% slower compared to the grep CLI but that's an apples to oranges comparison because if you already have a php thread running doing an extra ggrep call in userspace is going to be faster then grep because the binary doesn't need time to load into memory.
I just wanted to throw this code out there in case it's useful to anyone but I was considering write a new one for ripgrep or ag because they are both faster than GNU/Grep.