Zend Weekly Summaries Issue #354

      2 Comments on Zend Weekly Summaries Issue #354

TLK: Namespaces or packages? [continued]
REQ: Reserved word alert
TLK: Nowdocs revised
TLK: Assigning bugs
NEW: PHP 5.2.4 RC2
TLK: Namespaced constants
REQ: PEAR .phar tests
CVS: Release cycle blues
PAT: Universal binary; messin’ with arrays

12th August – 18th August 2007

TLK: Namespaces or packages? [continued]

PHP user Richard Quadling did his best to define what the term “namespace”
meant to him, and came to the conclusion that ‘a namespace is a
programmers thing, whereas a package is more of a distribution thing.

Tijnema got into a small fight with Lars Gunther, who brought ECMAScript
4/Javascript 2 and XML into the debate at the end of last week. He
uses Java and C#, and felt it was ‘a bad idea to confuse people with the
same name for something different.
‘ Larry Garfield pointed out that for
the vast majority of PHP programmers, Javascript is far more likely to be the
other main language than either Java or C++. Tijnema started talking about
ASP.NET and perl programmers. Someone named Giedrius pointed out that, since
the PHP version is neither C++-style namespaces nor Java-style package,
it doesn’t really matter what name will be used. It will confuse newcomers
from any language anyway.
‘ Alan Knowles, responding to Lars, wrote that
the PHP implementation looks more like Javascript
to him than Javascript
in any case. Marcus Börger wrote that more PHP users know
C++ and/or Java than are familiar with Javascript (huh?) and besides,
namespaces are an imminent concept rather than an existing one in Javascript.

Guilherme Blanco tried to get people to list the features of namespaces and
packages and say how various languages (including PHP) implement them. This
would at least give a firm basis for the discussion. David Coallier liked
that idea, but thought it would be easier if everyone could see an example of
a python package, a Java package, a C++ namespace and a C# namespace. Needless
to say, everyone else ignored them both.

It gradually became clear that people generally saw “packages” as a limited
namespace implementation, and “namespaces” as the whole deal. As Ralph
Schindler explained when the subject of brackets predictably arose:

Greg Beaver was thinking along completely different lines; having a
PHP-specific keyword would surely kill this debate stone dead. He
came up with “prefixes”, which won a number of fans before the week
was over. Someone somewhere suggested “zendspaces” – hopefully they
were joking – which set Stas Malyshev off:

Tijnema ran down a side turning by attempting to test Johannes
Schlüter’s renaming patch on a snaps box distribution, but we’ll let
that one lie, since it only took ten emails or so to ascertain which
version of flex actually works these days. Marcus
engaged in direct combat with Stas for a while, grumbling that the
original namespace implementation – although it didn’t work – at
least had nesting and wasn’t bound to files. Stas mentioned that
there was probably a connection between the nesting part and the not
working part. Someone named Scott Lewis was attacking on another flank:

Meanwhile, Johannes continued to update his
renaming patch
to match Dmitry Stogov’s innumerable changes to the
implementation. Dmitry eventually came away from coding to explain that the
namespace concept and features are still under intensive development; he
personally wasn’t certain that the existing implementation would work well.
The PHP namespace implementation needed testing in real life applications and
frameworks; it needed benchmarking; the concept itself needed close analysis,
and all these considerations were far more important than the name. Dmitry
added that he’d personally accept “package” for the implementation as it
stood, but there was still the chance that it might need to be renamed back
to “namespace” at a later date.

Obviously, this didn’t stop people talking about the name. But it should’ve.

Short version: A rose is a rose is a rose…

REQ: Reserved word alert

Following an IRC discussion with the Doctrine community, Lukas Smith
wrote to internals@ to propose ‘a prominent place on php.net with early
warning for reserved words that will be in future PHP releases

Hannes Magnusson pointed smartly to http://php.net/reserved, a prominent place
on php.net that just happens to contain a list of current and future keywords,
predefined variables, constants and classes in PHP.

Alain Williams had other ideas, and shared his ‘nice simple rule‘:
just include a capital letter in userland names. Hannes retorted that
functions, class names and methods are all case-insensitive; this would only
work for variables. Tomas Kuliavas grumbled that it wouldn’t work at all if the
capital letter happened to be I
, but this turned out to be a bit of a red
herring for anyone not using a Turkish-based locale. Back on topic, Lukas
wondered aloud if a forward compatibility newsletter might serve users
better; ‘something that summarizes the last 4 weeks worth of BC breaks
‘. (German joke.) Lukas was still trying to decide whether he had
enough motivation to take on that task when Marcus Börger caught up with
the thread and told everyone to ‘prefix your code and be done!‘ Nicolas
Bérard-Nault and David Coallier linked forces to challenge him,
explaining that this issue had arisen through a class method rather than a
global function:

PEAR_ClassName {

    public static function PEAR_import() { }

leading to the horrible name PEAR_ClassName::PEAR_Import()
rather than the more usual PEAR_ClassName::import().
Pierre-Alain Joye agreed with them, saying that the rare case where a method
prefix would be acceptable is limited to magic methods such as
__get() and __set().

Ralph Schindler intervened to say that he’d raised this issue a long time ago
and been slapped down by Wez. He had a bit of a moan about the shrinking of
the global namespace and the lack of incentive on the part of the core
development team to address the problem by adding contextual awareness to the
compiler. Greg Beaver explained gently that ‘doing this with flex is
‘. Although it would be easier with a re2c lexer,
porting the flex scanner to re2c is a horribly
complex task and is correspondingly unlikely to happen any time soon. Adding
rules to the existing parser for reserved words would be ‘hackish‘,
both duplicating code and adversely affecting performance.

Short version: No change there then.

TLK: Nowdocs revised

Christopher Jones wanted to know the status of Gwynne Raskind’s proposal for
nowdocs. He believed it would be useful, when writing XQuery, not to have to escape
variables as currently:

$xq = <<<END
select column_value
from xmltable('for
\$i in ora:view("locations") return \$i')

and saw nowdocs, “a heredoc that acts like a single-quoted
string”, as an ideal solution.

Gwynne explained that it wasn’t actually up to her whether the
nowdocs patch went into the PHP core or not. However, the main
argument against it had been its relevance for PHP users, and Gwynne used
Christopher’s comment to re-open the debate.

Richard Quadling was quick to back Gwynne; he felt it would be useful to be
able to ‘code templates within PHP rather than as an external file without
any escaping or variable expansion
‘. Derick Rethans agreed; he didn’t see
why Gwynne’s patch shouldn’t go into the PHP_5_3 branch when it opens.

Stas Malyshev demurred. He wouldn’t mind seeing the patch in CVS HEAD, and
possibly in PHP 5.3.0… but he had doubts about back compatibility and about
the proposed nowdoc syntax, <<<~. Pierre didn’t see
that there was a BC issue; throwing a parse error for unsupported
nowdoc syntax is only the same as throwing a fatal error when a
non-existing function is called, and that risk is taken with every new
function introduced into the PHP core. Come to that, what’s so obvious about
<<< for heredoc? Stas pointed out that you can call
function_exists() to check for a function, but there’s no
equivalent function to check whether a file will choke on a parse error. As
for the syntax, Stas referred everyone to <<FOO and
<<'FOO' in Perl. Pierre retorted that
function_exists() returning FALSE has much the same
effect in any case, but Stas replied that it’s at least possible to work
around a missing function. There’s no option that allows people to work
around new syntax. That said, Stas was convinced of the usefulness of
nowdoc; he just was concerned about ‘creating code that runs
in one 5.x and can’t even be compiled by another.
‘ Pierre agreed that
code should work across all versions within a minor point release set, but
mentioned the introduction of the b binary cast in PHP 5.2.1.

Short version: Doesn’t anyone use version_compare() any more?

TLK: Assigning bugs

Wez Furlong blew a gasket when Jani Taskinen assigned him yet another batch
of bugs related to COM objects after almost a year of little-to-no
involvement in PHP development on Wez’ part. Wez fired off a note to
internals@ in which he pointed out that there are active maintainers
for ext/com_dotnet right now, but he isn’t one of them. Bugs shouldn’t
be marked “assigned” to a non-active maintainer; they’d be better left “open”,
where they stand more chance of being fixed by someone else.

Pierre noted that Andy Wharmby would have been a better assignee, and asked
him to take a look at all COM/dotnet bugs. He added that he hoped the new bug
tracker would allow mail to be sent to specific maintenance groups when a new
issue is raised, rather than to everyone as now. Hannes thought it would be
best if individual maintainers subscribed to an RSS feed for bugs related to
their given extensions – an option that already exists via Rmail. That said, a fixed list of
developers per category could be arranged… if anyone else thought it a good

Jani picked up his mail at this point and explained that the
EXTENSIONS file, which contains the maintainer list, specifies Wez as
the sole maintainer for ext/com_dotnet. He added as an aside that
this extension really belongs to PECL‘ – an old argument that was lost a long time
, during Jani’s absence. Strangely, nobody picked up the gauntlet.

Andy meanwhile had got back in touch to say that he’d been busy elsewhere for
the last few months, but would take a look at all the outstanding COM
‘defects’ in the coming weeks, whether they happened to be assigned to Wez or

Short version: Leave Wez alone!

NEW: PHP 5.2.4 RC2

Ilia Alshanetsky, as Release Master for the PHP 5.2 series, announced the
availability of the second release candidate for PHP 5.2.4 as follows:

Scott MacVicar noted that the Windows distribution needed a
libmysql upgrade – or downgrade – or change, anyway – in order
to complete the fix for a nasty bug
. He added that he regarded that particular bug as a showstopper; it
caused an error message to be printed at the bottom of every page while
holding MySQL connections open for a very long time. Scott had highlighted
the bug report to Edin Kadribasic some time ago without success, and now
wondered whether anyone else had access to the build farm. Ilia preferred to
leave library upgrades in Edin’s capable hands, but thanked Scott for his report.

Lukas, acting as PHP’s unofficial secretary, promptly added the Windows
libmysql upgrade to his PHP_5_2 TODO list. Looking
through that list, he asked Ilia for an update on the GD2 tests and PCRE
library upgrade. Ilia confirmed that the PCRE upgrade was in place; he didn’t
see the GD tests as critical to the release, and pointed out that he hadn’t
actually made this list himself. Tony and Pierre both chimed in at this point
with other libraries that should be updated prior to release. Ilia wondered if
there were any real reasons for upgrading them all, but Tony swiftly mentioned
the word “security”.

Edin turned up, explaining that he had very little time these days and asking
for a list of the libraries that needed updating. Scott obliged with
libmysql, pslib, libtidy and
snmp. Pierre added libpng, explaining that the
library has had ‘issues’ over recent months and he’d prefer to use the latest
version. He also asked Edin to update his infamous zip.zip – this being
the massive collection of libraries Edin hosts for the use of those building
PHP under Windows.

John Mertic reported a “403 – Forbidden” error when attempting to download
his PHP 5.2.4 RC installer, and added that the latest snapshot log gave an
“Access is denied” message. All he’d done was update the wix binaries in
CVS… Edin promised to look into it.

Stas picked up on Ilia’s note that the 5.2.4 TODO wasn’t his own work, and
wanted to know who was managing the TODO for PHP 5.3.0. Ilia replied that he
intended to create that list himself and post it online; if Stas (or anyone
else) had anything to add to it, he (or she) should email Ilia directly.

Short version: Quite a bit still to be done before the 5.2.4 release.

TLK: Namespaced constants

David Coallier had been wondering whether constants would ever be allowed in
namespaces, as per the original plan according to the Paris PDM notes. He’d
found that:

namespace MyPackage;
NAME = 'inspace';

currently throws a parse error. Alexey Zakhlestin pointed out that the
keyword const is only allowed inside class definitions;
define() should be used elsewhere. David already knew that; but
define(), as he
went on to demonstrate
, creates constants in the global namespace. What David
hoped to see was a way of declaring and calling a namespaced constant, i.e.

import MyNS as A;

Stas confirmed that the plan was and still is to allow the const
keyword in namespaces, but there had been problems in the implementation that
need hammering out. There were some ambiguities, and to date all attempts to
implement checks for them have had a negative impact on performance.

Short version: Background information.

REQ: PEAR .phar tests

Greg announced that he’d fixed and uploaded new versions of the
install-pear and go-pear phar files for PHP 5.2.4. These phars
distribute the latest stable PEAR (1.6.1) and Console_Getopt (1.2.3) packages.

Greg had already tested the PEAR install on Linux 32 and 64-bit and Windows
32-bit machines, but had no access to other operating systems. In particular,
he’d appreciate it if someone could test them on Mac OS X and Windows 64-bit

Short version: Testers (always) required.

CVS: Release cycle blues

Not much happened in CVS this week, due to the stage of the release cycle…

Prior to 5.2.4 RC2:

  • Configuration bug #42292
    ($PHP_CONFIG not set for phpized builds) was fixed [Jani]
  • Emanating from the SPL extension but affecting ext/simplexml, bug #42259
    (SimpleXMLIterator loses ancestry) was fixed [Rob Richards]
  • Core bug #41946
    (ip2long("") should return FALSE) was fixed in the
    5_2 branch (fix not needed in CVS HEAD) [Jani]

Following 5.2.4 RC2:

  • Core bug #41904
    (proc_open with empty array as $env should pass
    empty environment to process) was fixed [Jani]

Meanwhile Dmitry Stogov quietly got on with improving the namespace
implementation in CVS HEAD. It runs a bit faster now.

Tony found that an elderly fix
from Brian Shire that changed printf %u behaviour on 32-bit
machines was responsible for breaking Greg’s PEAR phar installation on
64-bit machines. Either ext/phar should be changed or the patch must
go. Cristian Rodriguez noted that the phar extension was in fact fixed
in CVS; it was just the PEAR phar file that wasn’t. Ilia agreed that
the C behaviour was correct, and hoped the adjustment for the PEAR installer
would be slight. Greg grumbled that he’d been forced to change working code
in PHP_Archive on three separate occasions because of bug fixes that broke BC
in pack()/unpack(); ‘I would appreciate it if
this is the last change of this nature that I need to deal with.
‘ In
fact, he was seriously considering writing a userland version of
unpack() to get around this problem.

Stas evidently thought things were far too quiet. He reverted Etienne
Kneuss’ patch to allow dynamic referencing of static class members, along
with all the affected test scripts. Jani arrived first at the scene of the
crime, and demanded to know what was wrong with that patch? Stas explained
that a major syntax change shouldn’t go into a minor release; this should
wait for PHP_5_3, or PHP_6_0. Beside, its reversion had been discussed
(off-list) and confirmed with the Release Master. Ilia confirmed this, and
explained that Dmitry had made the request. Ilia had agreed with Dmitry’s
assessment that this was too big a change to go into PHP 5.2.4 at the very
last minute, and had asked Stas to revert the patch. However, the code could
go back into CVS following the 5.2.4 release, in Ilia’s estimation. Hannes
pointed out that this information was missing from the NEWS file, and
Stas promptly updated it. Then Hannes exploded – not because he
disagreed with the decision, but because it hadn’t been publicly discussed.
Lukas backed his complaint. The problem was one of transparency; Zend patch
reviews never seemed to have a public follow-up. Beyond that, the commit
message “Revert variable class patch for 5.2” wasn’t informative enough to
prevent outrage on the part of the development team.

Andi Gutmans explained. The patch had been fully reviewed, and the Zend team
were all for it, with that one caveat that it shouldn’t go into the Engine so
late in the release cycle. They’d communicated this to Ilia off-list, who had
promptly requested its reversion, again off-list. There had been no response
and, since time was running out, Stas had volunteered his services.

Hannes was much relieved to find that this wasn’t a case of the Zend team
operating unilaterally, but grumbled that the rest of the team didn’t have
access to anyone’s private mail. Johannes Schlüter, who had been
responsible for committing the patch, thanked Andi for the feedback but wrote
that he’d been travelling and must have missed the email requesting reversion.
It would be better to send that kind of message to internals@ too, despite the
risk of provoking a long discussion – which, he added ironically, ‘some
“random” revert
‘ might provoke in any case.

Short version: Greater transparency offers a way out from future

PAT: Universal binary; messin’ with arrays

Christian Speich came back as promised with the results of his universal
binary testing: Tony’s patch didn’t work. Christian had been thinking it
over, though, and posted
the code
as he thought it should appear. Tony agreed that this version
was probably correct, and a jubilant Christian reported success a while

Hannes offered up a patch introducing a new Boolean parameter,
keep_pos, to both in_array() and
array_search(). If keep_pos is TRUE,
the internal pointer would be set to the first location of
$needle in $haystack, assuming the
$needle exists, thereby making it possible to search for a value
in an array and then run prev() or next() to pick up
the value of a sibling. Another alternative might be to create two new
functions with that functionality:

bool array_seek_value(&$array, mixed $value [, bool $strict=false]);
bool array_seek_key(&$array, integer/string $key);

David Zülke didn’t like the first idea at all: ‘Smells like feature
creep. Plus, it’s difficult to document. I think it would be the first
function that mutates an argument depending on another argument – it would
also mean that the input array is passed as a reference in case that new flag
is set.
‘ Nobody commented on the second idea.

Short version: Triple-decker somersaults for arrays on offer. Any takers?