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:
1234567891011121314151617181920 <i>The PHP Team has just released the first release candidate forPHP 4.4.0. This is solely a bug-fix only release, the increased middledigit is needed because this release changes PHP's Internal API,causing third-party binary extensions to be incompatible with PHP 4.3.x.This release addresses a major problem within PHP concerningreferences. If references were used in a wrong way, PHP would oftencreate memory corruptions that would not always surface and bevisible. In other cases, it can cause variables and objects tochange type or class. If you have encountered strange behavior likethis, this release might fix it.Besides addressing this reference related bug, 46 other bugs arefixed. Please test this release and report any bugs or problems inour bug system (after searching first).If all goes well I plan to roll a release of 4.4.0 on June 27th. Ifthere are problems a new RC will follow. Only critical bugs aregoing to be fixed between RC1 and RC2.</i>
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:
|
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:
|
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:
|
Zeev argued that this was a nuance; it would usually make more sense to simply
assign the variable with the required value:
123456 <i>Fact is that it's possible to implement <code>ifsetor()</code> functionalitytoday in userland. We cannot go around implementing a new constructfor every possible thing that someone might need. This should beimplemented in userland, even if it has a small side effect. It givesyou the full power of doing whatever you want, instead of being limitedto what a low level construct does.</i>
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
|
$variable
was guaranteed to be set. She hoped to kill the need for the
implementable but ugly ternary,
|
and allow something like:
|
Zeev pointed me to a
strange construct in Perl. When I’d finished laughing, he rammed the lesson home:
123456789 <i>I'd be hard pressed to explain why 'unless' is not a good idea, sinceI'd have to give out exactly the same reasons (it's obscure, and itdoesn't allow you to do anything that you cannot do today; but that'snot valid justification, right? why not add it then?)ifsetor =+== unless (*)(*) =+== is an operator that means that two concepts are identical innature, coming up in PHP 6.</i>
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:
123 <i>If you leave E_STRICT enabled but try to bypass it (by declaringeverything as public for BC) then you didn't understand what E_STRICTis for...</i>
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')
in PHP 5. Why, asked Michael, has
&& ($obj instanceof ClassName);
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
:
12345 <i>If PHP 5 is (rightly) considered a runtime engine then its job shouldbe to evaluate and execute code and in the case of failure, explain whyit could not do so. In other words, if a code segment is valid, then theruntime should just do its job and run that code. Code correctness isthe job for offline tools like lint.</i>
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:
1234567 <i>E_STRICT is a wonderful idea - I just wish it was implementedseparately from the normal error handling, that's all. An importantthing to remember is that a client's configuration, PHP version andcode base mix is typically out of my control and I don't like lookingbad just because the runtime is taking it on itself to tell the worldabout irrelevant differences between PHP 4 and PHP 5. Those differencesare important to you and me, not to end-users.</i>
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
|
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.