Zend Weekly Summaries Issue #185

      Comments Off on Zend Weekly Summaries Issue #185

FIX: Sybase-CT extension
TLK: Variables in php.ini > PHP 5.0 release date
NEW: private/protected/public and var_dump()
TLK: gif support in bundled GD
TLK: Module dependency load order
TLK: PDO design

FIX: Sybase-CT extension

Timm Friebe had an interesting time, starting when he fixed an outstanding group
of bugs in ext/sybase-ct at the end of last week. Alex Kiesel wrote in to complain
that this introduced a behaviour he considered broken. Timm agreed, and fixed this
promptly. Ard Biesheuvel then reported that this latest fix broke ext/sybase-ct on
64-bit architectures. The fix Timm produced for this broke the ZTS build, so he
fixed that too. He ended this week by providing a fix for a more recent bug whereby
calling sybase_free_result($result); would cause PHP to crash.
Hopefully all is now in order!

Short version: Sybase-CT support works now.

TLK: Variables in php.ini > PHP 5.0 release date

Andrei Zmievski’s patch for php.ini variables having been delayed due to the
feature freeze led directly to a long and fairly heated discussion about the
reasoning behind the feature freeze, PHP versioning, the PHP release process, the
role of Zend in PHP development, the size of hamsters’ ears, etc etc ad infinitum.
Sara Golemon eventually had enough of the nitpicking and exploded with a passionate
of the release process as it stands. Zeev Suraski responded warmly,
saying that he agrees with everything Sara says. Sara now has this tattooed on her

The discussion mutated at this point to being about the number of release
candidates that might still be needed before PHP 5.0’s release, the pacing of them,
and the release date that internals developers should be aiming for now. The
consensus comes down to ‘some time in July’.

Short version: RC3, possibly RC4, and a July release expected for PHP 5.0

NEW: private/protected/public and var_dump()

Sara asked whether the current print_r() behaviour – displaying all
properties regardless of their status and explicitly identifying private and
protected properties – was actually correct, sparking another discussion. The team
agreed that both print_r() and var_dump() should be used
for debugging purposes only, so there was no point in hiding private/protected
properties in these functions and var_dump() should be changed to be
consistent with print_r() behaviour. Andrey Hristov applied a patch to
make this effective. There is as yet no decision whether properties declared as
public will be identified as public: in the same way; there is a strong
argument that adding this could break BC and also, even if this is avoided, much of
the test suite will need to be rewritten to accommodate such a change.

Sara also provided a patch providing get_object_vars() with a more
finely-grained version of private/protected/public declaration, dependant on the
access allowed from wherever the function is called from. Her submission got lost
among other discussions for now, and so no decision has been taken over this.

Short version: var_dump() displays everything now, same as print_r().

TLK: gif support in bundled GD

Andrew Sitnikov sent in a patch for review that provides gif support for PHP’s
bundled GD library, explaining that the Unisys patent regarding LZW compression is
due to expire in several countries between now and July. Derick Rethans was quick to
point out that July 7th – the final date on the patent expiry list – is still in the
future. Rasmus Lerdorf stated that he had intended to make a patch available from
June 20th, when the patent expires across most of Western Europe and Japan. Andi
Gutmans argued that there isn’t enough of a gap between June 20th and July 7th to
justify the confusion that such a patch might cause Canadian PHP users, Canada being
the final country on the expiry list.

Short version: No writeable gif support before PHP 5.0.1. “Blame Canada.”

TLK: Module dependency load order

Wez Furlong submitted a patch for review that is designed to initialize modules
in order according to their dependencies during the build process on non-win32
systems (the new-ish win32 build has this already). Andi Gutmans objected that this
was a little late in the day, coming as it does so late in the release schedule, but
added that if others felt it was important, and if the patch could be tested across
a wide enough range of systems, he wouldn’t prevent its acceptance into CVS. Rasmus
Lerdorf added that, in his opinion, people shouldn’t be trying to build extensions
statically in the first place, but loading them at runtime. Meanwhile everyone with
access to a strange system rushed to test the patch, not least because a static
build is less hassle for testers, but also because PDO has a fairly involved
dependency setup, and everyone involved has one eye on releases beyond PHP 5.0.
There has been no decision made as yet.

Short version: Static builders rejoice! An extension init() order is
(hopefully) on its way!

TLK: PDO design

Ard wrote to the internals list asking whether multiple transactions should be
allowed for in the base PDO (PHP Data Objects) design. Wez explained that a major
concern was to keep the core PDO API portable as far as was possible, and added that
if multiple transactions/database connections were allowed in a range of database
systems other than Firebird he would prefer to create a separate API that could be
loaded via PDO to allow this option. If only Firebird – which Ard used as his
example – was affected, the requested behaviour should be specific to the Firebird

Short version: PDO is generic by nature and modular by design.