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

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 packages to him than Javascript namespaces 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:

...having braces is not for vanity's sake, and is truly important to
the implementation thus lending itself to actual naming of the
implementation.

a) BY NOT HAVING BRACES you have subscribed to FILE BASED scope
termination, thus tying the SCOPING of namespaces to a FILE.

b) BY HAVING BRACES you would be subscribing to a model that
terminates scope of namespace constructs to current scope they are
defined within.

The former lends itself to being called a "package"; the latter lends
itself to being called a "namespace".

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:

So it goes like this:

PHP Group: "Good news everyone! PHP now has zendspaces!"
PHP users: "WTF???"

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:

PHP Group: "Good news everyone! PHP now has namespaces!"
PHP users: "Awesome!"
PHP users: "Wait.. WTF? These don't act like namespaces - where are
            the braces?"
PHP users: "These act more like... Java packages. Why are they called
            namespaces?"

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:

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 non-trivial'. 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:

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 idea.

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 ago, 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 not.

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:

As promised two weeks ago, the 5.2.4RC2 was released today and the
sources for the release can be found here:

http://downloads.php.net/ilia/php-5.2.4RC2.tar.bz2
(md5sum: dc6589d253b4ac5010603c5927f33546 )

Windows binaries should become available in short order as well.

All in all the feedback on RC1 has been largely positive and since it
was released another 20+ fixes were added to the code as well as a
plethora of new test cases, which bumps up the code coverage to 53%.
The number of changes in the CVS have petered off in the last few
days, which is usually a sign that we are ready for a final release,
or that everyone is on vacation. Please try this RC out on your code
and report back any critical issues you may discover. If all goes
well, the plan is to have the final release done by the end of next
week.

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 there. 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:

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.

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 boxes.

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 misunderstandings.

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 later.

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:

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?