Zend Weekly Summaries Issue #237

      Comments Off on Zend Weekly Summaries Issue #237

REQ: print_r plus pre tag
TLK: PHP-GTK corner
FIX: Unserialize bug
TLK: PDO and abstraction
TLK: Classes in print_r
TLK: GCC 4.0
CVS: PDO, DOM, SPL, build and cookie fixes
PAT: Nothing new under the sun

REQ: print_r plus pre tag

Ante Drnasin wrote in with a request for a very small and simple function, saying
that although it was easy to implement in userspace he (and everyone else) was using
it for debugging their PHP scripts. It would be handy to have it as a built-in
function. In PHP terms, it looks like this:

* Prints the variable in HTML format...
* @param mixed $var
* @param bool $return return or print the var
* @return string
function print_pre($var, $return
= false) {
= '<pre>'.print_r($var, true).'</pre>';
$return) return

Benj Carson wrote saying ‘oddly enough, we have virtually exactly the same
function and use it everywhere too
‘. However, in his company they add a
check against php_sapi_name() so it will work with CLI too. While it
didn’t seem essential for the core, if it were built-in he’d certainly use it.

Petar Nedyalkov was dismissive; the Reflection API was enough for him, and basic
debugging such as this was a non-issue.

Greg Beaver suggested they should either use the html-ized
var_dump() in pecl/xdebug, or else simply put <pre
tags around var_dump(), or even just use
var_dump() and ‘view source’. Marcus Börger pointed out that nobody
would need to change anything if they wrote their favourite debug function in a
separate file and auto prepended the file via .ini settings.

Sean Coates suggested asking for new features in the
proper place
. ‘Click ‘report a bug’ and choose
‘Feature/Change Request’ as the ‘Type of bug’
‘. Derick Rethans’ email arrived
nanoseconds later: ‘But don’t bother – this was requested before and

Sara Golemon came up with a simple patch you can apply ‘if you really-really
want it in your own build
‘ adding a second optional Boolean parameter,
pretags, to the standard print_r() function. This is
currently stored in PAT, on the assumption that
there may well be web development houses out there that would like the option to
have this built-in on their non-production boxes.

Short version: Basic HTML-friendly print_r() patch available – no
documentation or guarantees given.

TLK: PHP-GTK corner

Markus Fischer continued last week’s good work with another handful of bug
reports and patches for GtkTreeView and GtkTreeStore.
After a while, Andrei Zmievski pointed out that Markus still had commit access to
the tree from the last round of PHP-GTK development. Markus thanked him for the
implied invitation, but said he’d rather Andrei review his patches first.

Meanwhile Scott Mattocks inadvertently started WWIV when he started asking around
for ‘May News’ for gtk.php.net.
Christian Weiske suggested that he might mention that PHP-GTK 2 has parameter
reflection now, making his Reflection Browser project capable of being used as
simple documentation.

Andrei, the project leader, hadn’t approved this change in the PHP-GTK 2 source,
and wrote a fairly stiff email to Christian on the subject of discipline in open
source development:

Christian was quick to point out that it was disabled by default, and
almost equally quick to add that reflection information constructors and static
functions hadn’t been implemented yet.

Andrei simply asked him to send the patch for review first before committing
again: ‘Mine is a benevolent dictatorship, but still a dictatorship :)‘. He
also disagreed over selective compilation, saying that a feature should either be
there or not there. The first thing, in that case, would be to remove the ‘enabled’
check and always add reflection information. He added that it would be entirely up
to Christian to make sure that every element had the necessary information; he
didn’t have time to maintain that himself. Christian promised faithfully to be
Andrei’s slave in this matter. Then it was back to business, after a couple of
questions and answers about the implementation (and one ‘Ugh, so much trouble for
so little payoff…
‘ from Andrei), and Scott dared peek over the battlements
once more.

Nicholas Escuder wrote in to say he was trying to port an application to PHP-GTK
2 and had found a class missing. Would it be fixed? Andrei answered in the
affirmative, and asked whether anyone had time to set up a Wiki page to track
missing functions and classes.

Simon Wheeler, who packages PHP-GTK as part of his PHP/Apache/MySQL starter-pack
bundles, mailed the list with the inevitable buildconf issues – this time on debian.
Markus was sympathetic, saying it was ‘really tricky’ under debian, and listed the
build tool versions he’d found to work on his box.

Short version: Reflection is enabled in PHP-GTK 2.

FIX: Unserialize bug

Timm Friebe wrote to internals@ to alert the dev team to the fact that
unserialize() would only work with a very limited range of characters,
whereas it should work with all characters allowed by the parser. He’d
established both cause (a change from Marcus B in mid-February to disallow illegal
class names) and fix (allow all names allowed by the parser), but didn’t have any
development tools available currently. ‘Oh, and BTW, this affects all
‘, he added casually.

Christian Schneider was there within a few hours with a fix, which Jani applied
once he’d figured a means of evaluating it without documentation.

Short version: It’s safe to unserialize an umlaut again.

TLK: PDO and abstraction

One Nicholas Telford had been looking into PDO, and noticed that
PDO::query() always returns a PDOStatement object. He felt
this would mean that any abstraction using PDO would either need to use
PDOStatement as its result set object, thereby defeating the argument
that PDO is not an abstraction layer, or else create its own result set object and
populate that from the returned PDOStatement result set, which seemed wasteful as it
would involve instantiating two objects for the same task. He proposed allowing
PDO::query() to return a subclass of PDOStatement as a
second parameter, thereby allowing abstractions to tailor the result set to their
own needs.

All that would then be needed to get it to return a custom result set would be
something like:

= $conn->query($sql,new

Nicholas added that he wasn’t equipped to provide a patch – only the

Lukas Smith pointed him to the last item on his PDO
FAQ page
, and told him that Marcus is planning on making it less clumsy (read:
easier to use) than it currently is. Nicholas was glad to see his idea had already
been thought of and implemented, if only roughly. Wez Furlong pointed out that he’d
need to be careful not to override either current or potential built-in methods,
adding ‘You have now been warned that the traffic is dangerous; if you want to go
play in it, it’s your choice
‘. Nicholas said the same could be said of an
external framework or library, except they’d have the luxury of protecting important
methods with final, and asked whether parent::method()
worked with built-in classes. Wez replied that parent::method() should
work, but went on to make his initial point more thoroughly:

Nicholas retorted that if the developer of said library realized this
was an issue they might decide to prefix all the library methods with something
unique. He added that other OO languages must also suffer from this when users
decide to subclass a built-in class, or even one from an external library – in fact
anywhere a programmer can subclass a class not under their direct control. ‘I
guess the moral of the story is, it’s possible, just be careful with method naming

Lukas was concerned over the parent::method() idea, saying that it
would make the idea of further levels of abstraction being implemented in userland
code needlessly hard, because it would mean needing to wrap rather than extend. He
asked the PDO team (and Wez in particular) to make ‘an explicit extra effort
to prevent method naming crises arising, although he understood that as new
functionality was added it may well bring issues along with it. He added wryly that
he and Wez, at least, didn’t seem to have a large overlap in method naming – a
reference to the entire history of PDO, when they don’t seem to have agreed over
any method name.

Short version: Who needs rope to hang themselves with when they’ve got

TLK: Classes in print_r

Marcus wanted to alter the output of both print_r() and
var_dump() to show in which class a private property was declared. He
explained that, at present, both functions simply state that a property is private,
so it’s impossible to tell which class level it belongs to; and if a derived class
has a private property with the same name, it’s equally impossible to distinguish

Wez took a look at the proposed change, and only asked that the ordering of the
output be changed from name:visibility:class to the more intuitive

Short version: Too much IRC leads to yet another short thread with no
visible outcome.

TLK: GCC 4.0

Ilia Alshanetsky aroused a bit of a storm when he fixed ‘various compiler
‘ by removing the commas from the end of each enum list in
php_pdo_driver.h. Marcus immediately challenged this, saying that
allowing the additional comma in array initializer lists and enums was in the C
language from the first day
‘. Wez backed him, asking ‘Which compiler does
‘ in a way that would make most compilers want to deny everything. Ilia
welcomed the PHP development team to the wonderful world of GCC 4.0.

Marcus promptly told the world what he thought of GCC development as a whole and
GCC 4.0 in particular, but Ilia pointed out that OSX Tiger already ships 4.0 as the
default compiler and others were likely to follow suit, therefore it has to
be supported.

Wez asked if it was OK simply to ignore the compiler warning in future, and went
on to give the humble trailing comma a good press before suggesting that the GCC
development team were anally retentive. Derick and I both suggested Wez should
simply submit a bug report to them. More cautiously, Ilia agreed to review the GCC
documentation to find the necessary flags to make the compiler ‘less anal about
the syntax

Meanwhile Marcus had been doing some research, and found that the comma had in
fact not been standard C syntax until ISO C99. Perhaps Ilia should look for a flag
to enable that standard? However, he swiftly followed this with the fruits of his
next search; GCC 4.0 currently uses ISO C89 as its default language standard,
marking new additions to the C language as warnings or errors, but will use ISO C99
when it is fully implemented. ‘Bad bad bad‘, he concluded.

Joe Orton intervened with ‘Mmmmm, nice tasty FUD, guys‘, and said that if
the PHP development team cared about pre-C99 compilers they shouldn’t be using the
trailing comma. Some versions of the Tru64 cross compiler would also reject it for
the same reason. He also believed – wrongly, as it turned out – that GCC 4.0 would
only emit warnings over trailing commas if -pedantic was amongst its

Back at the www interface, Marcus found that GCC supports the -std
switch, allowing the user to specify the language standard. He wasn’t initially
certain whether Ilia should use -std=c99 or -std=gnu99,
but concluded that -std=gnu99 would be the hallowed version after
reading that it would eventually become the default standard.

Short version (thanks Jani): Sheesh… they’re just warnings. Ignore them. :)

CVS: PDO, DOM, SPL, build and cookie fixes

The first of those ‘mysterious decisions that come out of nowhere’ arrived when
Ilia renamed fetchSingle()in PDO to fetchColumn()following
a group meeting at php|tropics. The function has also been altered to support
specification of the column to be retrieved.

Ilia went on to apply a fix for ext/dom bug #33059, which Rob Richards asked
him to revert, saying he’d been working on it when his computer had gone into
meltdown: ‘First time I ever saw an error message saying things are screwed,
please reinstall operating system :)
‘. The fix was less straightforward than it
appeared, thanks to the way special attributes are handled as virtual nodes in
libxml, and there were five functions affected, rather than the single one mentioned
in the bug report. Ilia made a sanity check before reverting, and Rob applied his
fix as soon as he had an operating system on his dev box.

George Schlossnagle applied configuration changes to ext/mysql to
support building on newfangled 64-bit linux distros‘, and Jani updated the
bundled shtool version to 2.0.1 (bug #33023).

Marcus spent his time in Mexico tinkering with ext/spl‘s
ArrayObject(), adding the new functions
ArrayObject::getFlags() and ArrayObject::setFlags() among
other things.

Antony ‘call me Tony’ Dovgal fixed bug #32944, making session.use_cookies=off work as advertised.

Short version: Quiet week.

PAT: Nothing new under the sun

Blake Matheny was lucky enough to mail in his offering for
php_error_cb during the quietest week in some months; it got a thorough
review, if nothing else, in between the margaritas.

Blake’s idea was to allow for a custom error handler to be used, rather than
php_log_err. This was useful for custom logging of error types that
can’t be handled in userspace. He went to some length to explain usage before adding
that it had been tested in his workplace, where it was used to log errors to a MySQL
database for the company’s defect tracking system.

George was the first to respond, explaining that this was already possible
without patching the core; Blake should write a PHP extension instead, and change
the zend_error_cb() function pointer to his custom C function during
MINIT. Derick quickly added a note to call the original one afterward,
as otherwise he could break other extensions that modify the error_cb
such as pecl/Xdebug.

Blake wondered what was wrong with the solution he’d proposed; he felt there were
several advantages in patching the core rather than producing a custom extension.
Having something like this that is ‘just part of PHP‘ would be ideal from a
maintenance point of view…

George argued against Blake’s ‘advantages’; it was straightforward to load
extensions dynamically, and they only need to change when the API version changes.
He said that what Blake had was ‘essentially a special purpose extension‘,
and pointed out that the functionality was already supported in an existing
extension anyway.

Wez pointed out that Blake would need to write a custom shared library if the
functionality were in the core, which negated pretty well all the arguments Blake
had made against extension maintainability. The only strong point Blake had made was
that his idea gave the possibility of alternative prefixes, e.g. script:, file:,
socket: and so on. Still, said Wez, there is already a mechanism for logging to
files, and nobody had asked to be able to log to anything else ‘for quite some
‘. He didn’t see a clear benefit to the majority of PHP users in applying
Blake’s patch as it stood.

Blake decided to write an extension and ‘throw it out there‘, saying it
would still be possible to support the hoped-for naming convention and meet all his
own requirements. Wez said Blake was very welcome to submit his extension to
PECL, assuming he aimed to
encourage others to make use of it.

Short version: A new custom error-logging PECL extension seems likely.