Zend Weekly Summaries Issue #241

      Comments Off on Zend Weekly Summaries Issue #241

TLK: GCC 4.0.1
NEW: PHP 4.4.0 RC1
TLK: ifsetor (again)
TLK: Forward compatibility
TLK: instanceof
TLK: PHP 5.1 beta 2 status
TLK: E_STRICT
REQ: Multiple VM models
CVS: ZE 2 and datetime
PAT: ext/openssl, sapi/apache

TLK: GCC 4.0.1

Sebastian Bergmann opened the week with a complaint; a Zend Engine macro aliased
to an external symbol had suddenly started breaking his build. Jani Taskinen added
the existing bug report into
the equation as Dmitry Stogov and Andi Gutmans wondered aloud why this had suddenly
become a compilation error. Andi suggested a temporary #ifdef to get
around the breakage for the upcoming beta release, while awaiting a response from
the GCC development team on the matter.

Short version: More frustration over GCC 4.0.

NEW: PHP 4.4.0 RC1

Derick Rethans, acting as Release Master for the PHP 4.4 series, announced the
first release candidate for PHP 4.4.0 RC1:

You can find 4.4.0 RC1 at http://qa.php.net/~derick/php-4.4.0RC1.tar.bz2
[dead link].

Short version: An end to reference issues in PHP 4. Hopefully.

TLK: ifsetor (again)

Terrier-like PHP user Ron Korving continued to gnaw away at the ins and outs of
ifsetor(). He felt that the real problem with creating
isset()-like functions in PHP was the E_NOTICE generated
when unset variables were sent to a function. If it weren’t for that, people could
write their preferred version of ifsetor() in userland code. Robert
Cummings offered a
couple of implementations that are in fact possible in PHP without throwing
E_anything, but added that a built-in function would do this much
faster. It would also get around the issue of name collisions, he said. Noah Botimer
wrote in to voice his support for Robert’s perspective before going off into a
fairly pointless discussion about ifsetor() implementation with Ron,
who gave an example of E_NOTICE-throwing code as he argued his corner:


function
ifsetor(&$var, $default =
null) {
    return isset($var) ? $var : $default;
}

One Sebastian Mendel was quick to point out that this implementation does not, in
fact, throw an E_NOTICE. Zeev Suraski seized the moment to explain that
the only problem with Ron’s userland version was that it pollutes the symbol tables
with empty variables; it would use up memory due to this, but would work. A more
practical userspace implementation, though, might be something like:


function
ifsetor(&$x, $default =
null) {
    if (!isset($x)) {
        $x = $default;
    }
    return $x;
}

This satisfied most of the complainants, but Marcus Börger came into the fray to
argue that not every case could be covered in this way:


function
ifsetor(&$a, $def = false) {
    return isset($a) ? $a : $def;
}

$a = array();
 $x
= ifsetor($a[12][34], 42);

Zeev argued that this was a nuance; it would usually make more sense to simply
assign the variable with the required value:

He went on to say that performance wasn’t a good enough reason to introduce a new
construct; such an approach would lead to PHP being cluttered with constructs for
everything, pointlessly. ‘It’s no scoop that C is faster than PHP.‘

I’m afraid I lost the plot in between everyone’s ideas of what
ifsetor() should or should not be, so I asked Sara Golemon (for) and
Zeev (against) to explain their respective points of view in words of one syllable,
off-list.

Sara wrote that her version of ifsetor() isn’t possible in
userspace. Any variable passed into a userspace-defined ifsetor() would
be set in the process; for example, in


function
ifsetor($variable,
$default)
{
    return isset($variable) ?
$variable : $default;
}

$variable was guaranteed to be set. She hoped to kill the need for the
implementable but ugly ternary,


$foo
= isset($_REQUEST['foo']) ? $_REQUEST['foo'] : 'bar';

and allow something like:


$foo
= ifsetor($_REQUEST['foo'], 'bar');

Zeev pointed me to a
strange construct in Perl. When I’d finished laughing, he rammed the lesson home:

Short version: ifsetor() won’t be implemented unless there’s a much
stronger argument for it than those given so far.

TLK: Forward compatibility

Lukas Smith wrote saying it might be a good idea to add public to
the PHP 4_4 branch, thereby allowing a degree of forward compatibility with PHP 5’s
E_STRICT. This would be simple to implement (a one-line patch,
according to Ilia Alshanetsky), and was really a political decision; Lukas felt it
would facilitate the move to PHP 5 for many users.

Stas Malyshev pointed out that adding the public keyword at this
stage had the potential to break existing PHP 4 code. Furthermore, code written for
4.4 and relying on the keyword wouldn’t be compatible with earlier PHP 4 versions;
anyone upgrading to 4.4 would have all of the restrictions but none of the
advantages of PHP 5. How was this good?

Rasmus Lerdorf and Andi were both slightly bemused – why would supporting
public in PHP 4 make such a big difference to PHP 5 adoption? – but
didn’t see it as a Bad Thing[TM]. Rasmus (and a few other people) wondered why
var hadn’t been supported as a synonym for public in PHP 5
from the start, promoting backward rather than forward compatibility. Andi explained
that it was intended to help developers find incidences of var in their
PHP 4 code and allow them to be explicit about the access modifiers under PHP 5. It
only happened under E_STRICT, which was intended as a strict standards
flag for perfectionists, and websites shouldn’t be running under that level of error
reporting.

Derick tried to kill the thread by saying that he’d read everyone’s ideas in this
fairly lengthy discussion and had decided not to allow any kind of forward
compatibility in PHP 4.4.*.

Rasmus, having thought it through, agreed that any changes on this score should
be in PHP 5. He added that E_STRICT currently was just strict enough to
be annoying with the warnings about var but not strict enough to be
useful; there was no warning about undeclared properties. Zeev pounced on this,
agreeing that there should be an E_STRICT warning in the case of
undeclared properties. The code was actually in place for that to throw an
E_NOTICE, but had been commented out because E_NOTICE was
too aggressive and E_STRICT hadn’t existed at that time. He felt,
though, that the E_STRICT warnings over var should stay,
and Derick agreed with him.

It was left to PHP user Nelson Menezes to have the final word on the subject:

Short version: The whole idea of forward compatibility is very, very weird.

TLK: instanceof

Michael Wallner mailed the internals list to complain about the behaviour of the
PHP 5 version of is_a(), the instanceof operator. Unlike
is_a(), instanceof needs to have a class already loaded,
and will throw a fatal error if there is no such class. The simple PHP 4 test,
is_a($obj, 'ClassName');, becomes class_exists('ClassName')
&& ($obj instanceof ClassName); in PHP 5. Why, asked Michael, has
is_a() been deprecated and replaced with an operator that doesn’t
provide the same functionality and can even be harmful?

Alan Knowles was quick
to back Michael.

Andi looked into the problem, reporting back simply that it seemed to work. A
bemused Michael asked, ‘Sorry, what seems to work what way?‘. Andi explained
that instanceof calls __autoload(); he’d assumed this
behaviour was broken. Michael wondered why this behaviour was in place at all, given
that ‘if the class is not defined, no object can be an instance of it‘, but
Andi felt there was no reason to change it because __autoload() is a
generic way of fetching classes. Wez Furlong intervened at this point to remark that
throwing a fatal error in code intended to avoid a fatal error seemed ‘a bit
over-zealous‘, and suggested that instanceof should simply return
FALSE in the event of an __autoload() failure.

Short version: Inconclusive discussion over error levels.

TLK: PHP 5.1 beta 2 status

Andi reported that PHP 5.1 beta 2 needed a little work before it could be rolled.
This included datetime behaviour changes from Derick, testing for a patch allowing
internal functions to return reference, and the module startup order patch. He felt
it would be possible to commit the latter after the beta was rolled if necessary, as
it would be relatively straightforward to test. He hoped to roll the beta on
Friday.

Derick wrote in on Friday to say he had a bug outstanding in the datetime area
that had most of the tests failing, and would like to fix it before there was any
kind of release. Andi agreed to wait for this.

Short version: Small reprieve thanks to datetime bug.

TLK: E_STRICT

Smarty developer Boots feels that there is something wrong about E_STRICT:

He argued that E_STRICT shouldn’t throw messages for code that the
Zend Engine is capable of handling, e.g. var.

Zeev pointed out equably that E_STRICT wasn’t on by default, or even
part of E_ALL; he failed to see how it could possibly hurt anything.
Sara backed him, saying that the default error reporting level throws no such
warnings; E_STRICT simply provides a way for script developers to find
code that should be updated. In fact, she felt it could happily be expanded to
embrace all deprecated methods. Zeev reckoned this was a good idea, too. Robert
Cummings was less enthralled with it all. He made the point that script developers
were not always in control of the environment their scripts were running under, and
when E_STRICT is enabled there are suddenly complaints from their users
that the code is broken, when in fact it is not. Boots, meanwhile, was fighting off
the many developers who chimed in to say much as Zeev had said; his point was that
non-error conditions should not be reported as errors at runtime, for
precisely the reasons Robert had given earlier. PHP 5 is capable of running PHP 4
code, and should simply do so. He added:

Dan Scott noted that actually E_STRICT was ‘default’ in
php.ini-recommended for PHP 5.1. He felt that this might be confusing for the
script developers’ user base. Jani argued that a) the recommended settings also
include error logging, b) the ‘default’ setting in the distributed .ini files
wasn’t reflected in the source code, and c) cutting edge releases should have
a pedantic error reporting level. Zeev and Rasmus joined forces with the view that
the settings in php.ini-recommended are geared to a production environment,
and Andi subsequently amended the file.

PHP user Jason Garber suggested Boots should use something like


if
(AppDevLevel ==
'Production')
{
    error_reporting(E_ALL);
} else {
    error_reporting(E_ALL | E_STRICT);
}

to work around his issue, but Rasmus pointed out that most of the
E_STRICT checks are made at compile time. Stas suggested using
auto_prepend_file.

Short version: A simple way to disable E_STRICT on a per-script basis would be useful.

REQ: Multiple VM models

Sebastian Bergmann asked whether it would be possible to add the generated files
for all three VM models (CALL, GOTO and
SWITCH) into CVS, and have the --with-zend-vm configure
switch choose the correct combination of files. This would make it possible to build
the GOTO and SWITCH modes without having a working copy of
PHP on board.

Dmitry wasn’t too keen on the idea, saying that having generated files in CVS
could lead to there being too many versions around, although he wasn’t against
having them generated for official releases. Jani pointed out that not having
the files in CVS could lead to ‘a chicken’n’egg problem‘ if PHP was not
available on the system, and spent some time working on a patch that Dmitry was
reasonably happy with. Dmitry, however, asked him not to commit his changes at this
point.

Short version: Jani’s patch for generating all three modes is
here [dead link].

CVS: ZE 2 and datetime

Dmitry had a busy week. He began it by committing his optimization (read: new
implementation) of the specialized VM executor, and moved swiftly on to improve the
USER_OPCODE API – there is now the ability to dispatch from a user
handler to the internal handler of another opcode. He then made it possible to
return variables by reference from PHP’s internal functions (pleasing Marcus, who
not only understands this stuff but actually needs it for his
ArrayAccess interface), and went on to improve the extension loading
mechanism ‘with support for module dependencies and conflicts‘.

Derick had an equally busy week, overseeing PHP 4_4 branch and implementing the
datetime library in PHP 5_1 branch. He had a few battles there, trying to keep the
library free of PHP_* macros and other references so that it can be
used elsewhere once it’s capable of being built as standalone. We have a new
php.ini setting that already sounds promising – date.timezone.
Edin Kadribasic rolled up his sleeves and joined the datetime effort, cleaning up
various build issues amongst other things.

Jani spent most of his time trying to optimize the PDO build (inadvertently
breaking it for PECL/PHP 5.0 in the process), in between helping Derick with ‘the
date stuff’. He also updated the bundled shtool to the version released this week,
2.0.2.

Ilia helped a little with ext/date, but got waylaid into doing other
things. He added a new offset parameter, pos, to
stream_copy_to_stream(), and two (offset and
length) to substr_count(), which he subsequently optimized
for strings of 1 byte in length. He also added a new bindto socket
context option, used in ext/ftp as well as in the network and streams
API.

However, hero of the week is Wez, for finally dealing with the Catalan
translation team. There is now a phpdoc-ca module in place in CVS, and a
mailing list both for the team and for their commit messages.

Short version: ‘The date stuff’ looks interesting.

PAT: ext/openssl, sapi/apache

Hungarian PHP user Marton Kenyeres submitted a patch adding a sixth optional
parameter to ext/openssl‘s openssl_pkcs7_verify(). The parameter
specifies the name of a file that will be filled with the verified data, with the
signature information stripped. Wez evaluated and later committed Marton’s addition
to PHP 5.1.

William A. Rowe, Jr., offered a patch for review adding
php_apache_phpini_set() to sapi/apache/mod_php5.c (and
mod_php4.c, but there’s absolutely no chance of that happening). This would
make the PHPIniDir directive, already available in
sapi/apache2handler/, available to users of Apache 1.3. William added that
several of his administrators had found this feature useful.

Andrei Zmievski applied a patch from one M. Bretz fixing nested array_walk() and
user array compare functions. M. had previously reported the issue in a nicely-drawn bug report.

Short version: PHPIniDir directive for Apache 1.3/PHP 5 is in
PAT.