Re: RFC: phpdbg

It definitely seems the PHPDBG site and RFC both need work to explain the purpose of this tool to a larger audience than the select few who are currently excited about it, and I have offered to help get that sorted out over the next few days. (Thanks for reaching out Joe). The first issue seems to be "Why not just use XDebug". Sure, these are both for debugging but XDebug works in a very different way. For starters xdebug is meant to "latch on" to the existing engine and provide debugging information and breakpoints for analysis. It also provides remote config tools for sending those breakpoint responses to another server so you can have a nice shiny Mac GUI working with a remote SSH server. That is all lovely, but not what this tool is trying to do - which is provide a new SAPI to run your code through for debugging. From the ground up it is built and designed to do this, instead of hooking into other bits of another engine. XDebug allows you to run your code through Apache/Nginx and get this data back, PHPDBG asks you to run your code through a different SAPI which can get you the same data but in a much more efficient and internally less complicated way. So which should people use? Probably both. Should they both exist? Certainly. Which should be merged into the core? The one designed as a SAPI and not as a module. Not 100% sure what you'd use PHPDBG for? Even if you do not use it yourself it could be used by frameworks like Laravel/Symfony to create awesome console servers, REPLs, etc that are considerably more powerful than the tools currently available due to limitations in the existing SAPs. If you try creating a REPL in pure PHP right now you're going to cry, but PHPDBG would make that easier. All in all, having this SAPI distributed to all PHP developers wether they like it or not (or wether they know what it is or not) is hugely beneficial - and has no BC issues whatsoever. Also by keeping XDebug as a module which has to be intentionally installed by people that want it, there is the hopeful chance that people will continue to avoid accidentally installing it into production - which is bad for a bevy of reasons. http://nikic.github.io/2012/01/19/Careful-XDebug-can-skew-your-performance-numbers.html http://stackoverflow.com/questions/3522182/will-enabling-xdebug-on-a-production-server-make-php-slower On Fri, Nov 22, 2013 at 2:40 PM, Andrea Faulds <ajf@ajf.me> wrote: > > > On 22/11/13 08:44, Ivan Enderlin @ Hoa wrote: >> >> >> And please, with all my respect and without considering xdebug here, >> stop using the “de-facto [standard]” expression. A tool is not good >> because it is the only one to be in the place :-). >> > > Nothing wrong with saying it's the de facto standard. It is the de facto > standard, though that doesn't make it good. Maybe that's what you meant. > > Anyhow, I'd love for phpdbg to be included in PHP. Along with the CLI > server, it'd make PHP a lot more developer-friendly :) > > -- > Andrea Faulds > http://ajf.me/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >