On Wed, 30 Jun 2004, Gareth Ardron wrote:
> Does the examples I gave you before not count ?
Yes. It does not count.
> in this case, the __destruct() function within someOtherClass does
> absolutly bugger all.
You can't reference one object from another's destructor. PHP makes no
promises about
These tools are exactly what I'm looking for.
Thanks guys!
Mike
On Wed, 30 Jun 2004 06:07:51 +0200, Sebastian Bergmann
<[EMAIL PROTECTED]> wrote:
>
> George Schlossnagle wrote:
> > I believe xDebug supports this
>
> It does. When using PHPUnit2 with XDebug you get information about
> which
George Schlossnagle wrote:
I believe xDebug supports this
It does. When using PHPUnit2 with XDebug you get information about
which lines of code are covered by which unit test, etc.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5:
On Jun 29, 2004, at 10:52 PM, Michael Luu wrote:
Hi all. I've started poking/hacking around in the Zend source trying
to implement code coverage statistics for php files. The end goal is
to build php with a coverage option, place it on a test server, run
test suites, then see which lines of code in
I made a patch for bug #28325.
I'd like to see this one applied by the time PHP5 gets out of the door.
http://www.voltex.jp/patches/bug28325-preliminary.patch.diff
Regards,
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all. I've started poking/hacking around in the Zend source trying
to implement code coverage statistics for php files. The end goal is
to build php with a coverage option, place it on a test server, run
test suites, then see which lines of code in which files were hit
(more importantly which one
i've read the Zend API docs at php.net and they seem dated, but i haven't
found anything that deals with byref parameters using the new parameter
parsing API. so i have a few questions ...
1. Is it sufficient to have an zend_arg_info structure declaring that a
parameter is byref, and parse the val
On Mon, 2004-06-28 at 12:25, Florian Schaper wrote:
> > __destruct will get executed during request shutdown after the
> > communication has been shutdown. The only way to be able to write
> > from within __destruct is to deinitialize it at the end of the
> > script and therefore before the reques
On Tue, 2004-06-29 at 18:55, Marcus Boerger wrote:
> Hello Florian,
>
> there is no problem in calling resource destructors/terminators in your
> destructors. You simply cannot output text to your pages from them. If
> this is not true then we need to fix it. For example if an object of
> yours ho
Marcus Boerger wrote:
> Hello Florian,
>
> there is no problem in calling resource destructors/terminators in
> your destructors. You simply cannot output text to your pages from
> them. If this is not true then we need to fix it. For example if an
> object of yours holds a database connection and
Hello Jason,
to be honest i don't really care. Since i am a C++ guy who loves types
i'd appreciate automatic calling of inherited constructors/destructors.
But php does not have types and so the non implicit calling version
gives us a little bit more flexibility. Since we also don't have
polymorph
Hello Florian,
there is no problem in calling resource destructors/terminators in your
destructors. You simply cannot output text to your pages from them. If
this is not true then we need to fix it. For example if an object of
yours holds a database connection and your destructor executes some
SQL
Gareth Ardron wrote:
> On Mon, 2004-06-28 at 12:25, Florian Schaper wrote:
>
[...]
>( though I'd prefer the way destruct is called to be
> changed ;-) )
For what it's worth, i'd second that.
./regards
Florian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Maintenance of zeroconf extension.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
14 matches
Mail list logo
