Re: Zend API changes

This change also broke my extension. I'd like to have the extension be buildable with all of 4.x without user intervention, so I'm trying to figure out some way to handle the change via the pre-processor. I thought that ZEND_VERSION, defined in zend.h, might do the trick. Unfortunately, it is defined as a string, thus the C preprocessor won't perform any comparisons against it. Perhaps in 4.0.6+ there could also be a ZEND_VERSION_DOUBLE, eg: #define ZEND_VERSION_DOUBLE 4.06 Does anyone have any clever solutions to this problem that I could use today? thx. -danda > It's in everyone's interest to keep the API intact. The Zend API is now > fairly stable (I don't expect compatibility breaking changes in the 4.0 > line); Judging from the experience of PHP 3.0, there too, the API > stabilized around x.0.5. > > Zeev > > At 18:29 4/5/2001, Brian Foddy wrote: > >A small point I'd like to raise here. > > > >I noticed 4.0.5 made a change to the arguments of > >zend_hash_get_current_key > >by adding a "dupe" argument to the define and underlying function. > > > >This of course broke any external custom modules that are not > >changed appropriately. In this case the change was very simple, > >but it raises a good question... > > > >Are there some guidelines independent external modules can follow > >to remain more compatible between releases? I'm not questioning > >the right or need for underlying Zend API changes, obviously > >when such changes are made all functions inside the PHP collection > >are change accordingly. But are there suggestions to minimize > >these in the future and get better notified when they do occur? > > > >Thanks, > >Brian > -- Dan Libby <dan@libby.com>, author of xmlrpc-epi check out xmlrpc-epi -- a C library for xmlrpc with a fast PHP extension. http://xmlrpc-epi.sourceforge.net and learn about xmlrpc, enabling remote procedure calls over the net. http://www.xmlrpc.com