Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78611
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.41 cause and error)
Message-ID: <1415080851.2624.344.camel@localhost.localdomain>
To: Derick Rethans <derick@php.net>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Date: Tue, 04 Nov 2014 06:00:51 +0000
In-Reply-To: <alpine.DEB.2.11.1411031940310.13538@whisky.home.derickrethans.nl>
References: 
	<alpine.DEB.2.11.1411031940310.13538@whisky.home.derickrethans.nl>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHPDBG scope
From: pthreads@pthreads.org (Joe Watkins)

On Mon, 2014-11-03 at 21:03 +0000, Derick Rethans wrote:
> Hi,
> 
> This is based on an email conversation between Joe Watkins and me. I 
> asked him
> what the original scope of phpdbg was, and I've summarized his reply 
> here:
> 
> - PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb 
>   like commands to debug, and step through code.
> - Support for breaking on an opline, something that no userland PHP 
>   users would need.
> - Support for breaking on lines, was an additional step later.
> - For PHP programmers, which spend most of their time at the console.
> - Not "intended to cover PHP's primary domain of HTTP requests".
> 
> Then later, they "documented a way that you could use it to emulate an 
> HTTP request, by setting those superglobals and executing your index.php 
> - your code doesn't know the difference between a real request, and a 
> cli-like script with the same super globals set."
> 
> And Joe indicates, that with that addition, the "flood gates opened". He 
> also said that he "would still like to remain in that narrow scope, 
> phpdbg is still useful in it's current (pre xml stuff) form." and that 
> it was never meant to "usurp xdebug", as "that is not where we were 
> aiming, and it's an extremely unrealistic thing to even want."
> 
> And I very much agree that the above bullet points, is what phpdbg's 
> scope should be.
> 
> Joe, if I got this wrong, then please say so :-)
> 
> cheers,
> Derick
> 
> 
> -- 
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
> Posted with an email client that doesn't mangle email: alpine
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

Morning Internals,

	Thank you Derick.

        "Why should phpdbg scope be limited, and not extended?"

	It's not about limiting the scope of phpdbg, it's about defining it
properly.
	
	The right tool for the job is what we are talking about.

	phpdbg will *never* be able to do all the things xdebug can do, and it
would ruin it to try.

	In the same way, there are things phpdbg can do that would further
complicate xdebug (or even be impossible), and we shouldn't try that
either, obviously.
	
	"The original scope of a project and what it should be in the future
are not always related"

	True, but in this case it does actually matter. 

	You will never be able to load phpdbg in any SAPI and debug any web
request in a robust way. It was never intended for that, it is limited,
in that sense, because it's a SAPI.

	Being a SAPI allows us to do things you cannot do in an extension, such
as overriding Zend's memory management routines. We have features based
on these abilities.

	I very much agree that we should keep phpdbg within the scope it was
designed for.

	I'm not saying we should not extend the features of phpdbg, but, we
should do it knowing what it actually is, knowing that it is
fundamentally different to xdebug.

Cheers
Joe