Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70292
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <528FB31B.6020409@ajf.me>
References: <4E.7B.51208.63ACD825@pb1.pair.com>
	<CAF+90c895QCHqqdfCOjB0KXf9HYm9K90RjUv=-K7=t5kW=__iA@mail.gmail.com>
	<528E1AF6.9050201@php.net>
	<CALJZF3gWqkm1=cpEVKbhRfMSar6DT51tAgmrq3Kg7kAfB8ySRg@mail.gmail.com>
	<528E4093.5000503@gmail.com>
	<528F197B.7040802@hoa-project.net>
	<528FB31B.6020409@ajf.me>
Date: Fri, 22 Nov 2013 15:07:50 -0500
Message-ID: <CABDNdAEQiSK0M7=h-CzPuCB_aHmCxjcFstjiEuzqPhBSq2jQUA@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: phpdbg
From: pjsturgeon@gmail.com (Philip Sturgeon)

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-produc=
tion-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 =93de-facto [standard]=94 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
>