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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
