Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32099
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.182.191 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=WjZtFGlN1cedJcI/yUpvGy/10gamIyoc4aGEMJmJBlUQOuO2aLgTqN8pM69jF55PE5x3dIkOjZ1vEjo/VhpPFbwQ9uxcrg3URrILXqGP8PFI2oemlfLFdMZxPKeA+Tkqr0GncUKjeUvxpm+qS9MxIaDWApJ8/c/6kD92Av0orgE=
Message-ID: <ee59b7580709071207j2f2c0037x9bc532fb9eb9937b@mail.gmail.com>
Date: Sat, 8 Sep 2007 03:07:19 +0800
To: "Andi Gutmans" <andi@zend.com>
Cc: "Cristian Rodriguez" <judas.iscariote@gmail.com>, internals@lists.php.net
In-Reply-To: <698DE66518E7CA45812BD18E807866CEA2AAA3@us-ex1.zend.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <ee59b7580709040724y23427c4bq2f6cd3b2ee409276@mail.gmail.com>
	 <ee59b7580709040938t6bde9dd4na121b9a7b5cb3599@mail.gmail.com>
	 <849426349.20070904210047@marcus-boerger.de>
	 <ee59b7580709041919s2dbacb69pda3cfa6517f7e2d3@mail.gmail.com>
	 <ee59b7580709052246k13275370w6043ae3db4e879e@mail.gmail.com>
	 <698DE66518E7CA45812BD18E807866CEA2A93C@us-ex1.zend.net>
	 <alpine.DEB.0.98.0709070907550.20254@kossu.ez.no>
	 <7d5a202f0709070106r5cc0cbb0n2d58d6f8a4e1c9a3@mail.gmail.com>
	 <ee59b7580709070838w3bdfe06er55c78e9d7f1fb907@mail.gmail.com>
	 <698DE66518E7CA45812BD18E807866CEA2AAA3@us-ex1.zend.net>
Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and is_ref
From: planetbeing@gmail.com ("David Wang")

Here's my analysis of what the options are:

In my mind, the macros patch is actually unrelated to the GC patch. It
is a Good Idea (tm) to use macros to manipulate refcounts no matter if
the GC is enabled, disabled, present in the source, or not added at
all. The only question is whether to break source compatibility just
for the sake of the aesthetics and cleanness of using macros to
manipulate refcounts.

If one accepts that PHP should and will use macros to manipulate
refcounts in the future no matter what happens, then it's only a
question of when to break source compatibility. The choice is either
right now, or (if the GC is added) when the GC is added, or (if the GC
is not added) at some undefined point in the future.

Breaking it now instead of later might save some more work in the
future, because new refcount manipulations might be added that will
also have to be changed later. However, breaking it now without adding
a new feature (GC) might seem rather arbitrary to developers of PECL
extensions. Breaking it when GC is added might be an easier pill to
swallow.

It's probably also true that the work saved if we break source
compatibility early is not extremely significant: Replacing two
"z->refcount++"s in your code is about as much work as just replacing
one. It may also be true that the addition of GC might require the
source of some extensions that do heavy refcount manipulation to be
looked at at that point anyway (don't worry! I think this is actually
VERY unlikely, but nevertheless possible) so it might be more
efficient to break source compatibility at the point where the GC is
officially added.

In consideration of those points, and in the interest of moving things
along I am in favor of going with the version with ZEND_GC, but
removing that option when the GC is integrated in some form or
another. Deferring the source compatibility break is not very
expensive in any case.

David