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.
The plugin directly adapts code from GNU Grep, so they MUST release it under the GPL, as far as I understand.
> 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.
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.