RE: [PHP-DEV] Patch for macros for tracking refcount and is_ref

As far as I'm concerned you can commit it with ZEND_GC. If you don't have karma let me know and we'll commit it. Thanks! Andi > -----Original Message----- > From: David Wang [mailto:planetbeing@gmail.com] > Sent: Friday, September 07, 2007 12:07 PM > To: Andi Gutmans > Cc: Cristian Rodriguez; internals@lists.php.net > Subject: Re: [PHP-DEV] Patch for macros for tracking refcount and > is_ref > > 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