NEW: ./configure, SuSE and the AMD64
Hans Zaunere of the New York PHP Group wrote in to ask whether there was as yet a solution to the AMD64/SuSE configuration issues he'd highlighted a couple of weeks ago. Joe Orton replied, saying that there had been no objections to his --with-libdir patch and he would commit it at the end of the week if this continued to be the case.
Following another of those long silences for which the internals list is becoming famous, Joe committed his patch a few days later. He mailed the list once more, this time asking Hans – and any other interested party – to test the new configuration option and to get back to him directly if there were any problems with it, as he hadn't been able to test every PECL extension himself.
Short version: Run ./configure --with-libdir and then e.g. --with-mysql=/usr to pick up mysql libs stored in /usr/lib64.
TLK: Negative string offset continued
Mike Ford wrote in to add his opinion to the ongoing debate; [] is marked as deprecated in the PHP manual so should be completely dropped by PHP 6.0 if it was separated fully from {}, and he would dearly love to see $string{-1} introduced to the language. He'd also like to see substr() functionality folded into $string{x, x}, and the introduction of $string{$a:$b} to mean 'from offset $a to offset $b', but understood that this was potentially confusing syntax. Andrey Hristov pointed out that substr_replace($string, $a, $b) already existed and he didn't see any need for Mike's $string[$a:$b]on syntactical grounds. Ilia Alshanetsky said that using substr_replace() for the purpose of changing one char was "like using a tank for a flyswatter". He also argued for $string{-1}, pointing out that it was simpler to use – as well as much faster – than either substr($string, -1) for read or $string[strlen($string) - 1] for write, both of which are the current equivalents in PHP.
John Coggeshall didn't care about speed, saying that this would account for a very small portion of it, but backed the introduction of $string{-1}, as a matter purely of syntax.
Sara Golemon brought common sense to the proceedings as ever, pointing out that allowing $string{$a, $b} or $string{$a:$b} for write purposes was indeed a source of potential confusion, but that if this was going to veto the syntax for writes then to introduce it for reads would be inconsistent. However, she still liked $string{-1}, which she called "readable and cute".
Shane Caraveo brought a new dimension to the discussion when he explained Python's usage of the idea: there is $string[:2] to get the first two chars, $string[2:] to get everything after the first two chars, and $string[-2:] to get the final two. He called this "a great construct", but added that not many people were likely to use it if it were introduced to PHP due to back compatibility considerations. Paul G pointed out that the reason this was so very useful in Python was that the great construct could be used pretty much everywhere, not only in strings, but recognized that he could have killed the feature request by asking too much here.
Short version: Anyone whose dog hasn't had their say on this issue yet, get him to write to internals@.
TLK: spl interfaces
Following a flurry of ext/spl commits from Marcus Börger, the mysteriously-named 10t3k mailed in with a request for an interface named Serializable. Marcus replied that he had an idea that would allow streaming into/from a single stream if a certain interface were present, but he would like to discuss this with the others at the upcoming Frankfurt conference before attempting to implement it. This would leave every class responsible for itself.
10t3k responded that he had been thinking along similar lines. He added that Wez had mentioned having two more streams-related callbacks in the zend_object_handlers struct, calling __sleep() and __wakeup() for Zend standard objects. For BC purposes, Serializable would contain those two methods, and userland classes would automagically implement Serializable.
"Yep", said Marcus, "that's most likely what we're going to do".
Short version: Yet another reason to visit Frankfurt.
FIX: Reflection API
Timm Friebe wrote in to ask why Marcus had added the invokeArgs() method and function to the Reflection API, since call_user_func_array() and call_user_func() could be used just as easily to do the same job.
Sebastian Bergmann explained that he'd asked Marcus to add the new method and function because the call_user_func() duo didn't work seamlessly; he had to switch from OO to procedural style to use them alongside reflection.
Timm retorted that Marcus had forgotten to support static invocation: calling invokeArgs(NULL, $array) resulted in an error message.
Marcus fixed the omission and asked Timm whether he was going to be in Frankfurt...
Short version: Lots of ways to access user stuff now.
TLK: PDO meeting at phpconf
Following a brief discussion on irc, Lukas Smith realised that if he didn't organise a PDO meeting, nobody else would. Previous incarnations have been very informal affairs ('Hey kids, let's do the show right here!') but, with the PHP 5.1 release cycle to some extent relying on the readiness of PHP Data Objects, and Georg Richter of MySQL still against PDO in principle, the agenda has acquired some urgency.
Lukas made an announcement about the meeting on the internals list, and followed it up a few days later with details: interested parties should join efnet #php.pdo on Tuesday night at 21:00 CET (no chatter and no OT please). There will also be a physical meeting - in Frankfurt, naturally.
Short version: OK, that did it - I booked my flights.
FIX: isset and the new VM
Frank Kromann found unexpected new behaviour when toying with the new VM build; isset($arr[0]['id']); now throws a warning if $arr[0] is undefined, where it used to simply return false. Was this a bug, or merely an as-yet-undocumented change in behaviour?
Sara Golemon called it 'buggish' and added output from her own experiments that showed an E_NOTICE being thrown. Jason Garber voted with her. Andi Gutmans mailed in through a haze of nappies and hospital trips to say that Frank's email had somehow managed to catch his attention, and Dmitry Stogov took some time out from his SOAP work - of which there has been a lot lately - to commit a fix.
Short version: Normality has been resumed.
FIX: localeconv not working
Klaus Reimer mailed the internals list to complain that localeconv() did not return the correct thousands_sep or decimal_point in either PHP 4.3.9 or PHP 5.0.2. He had done some delving into the source code and found the lines:
if ((lc.decimal_point)[0] != '.') {
setlocale(LC_NUMERIC, "C");
}
This, as Klaus pointed out, would make it impossible for him to set LC_NUMERIC to, for instance, de_DE. Was there a workaround? If not, he had a couple of suggestions to make; either cache the original LC_NUMERIC setting in some way, or add parameters to localeconv() so that it could retrieve the settings for a given locale while retaining the standard 'C' setting globally.
Moriyoshi Koizumi replied that there was indeed a workaround: Klaus could save all the relevant environment variables beforehand and restore them with setlocale() after the localeconv() call. However, he added, this was indeed a valid bug. Klaus had already reported it as #30638 and it had been assigned to Derick Rethans, who wrote in at this point asking whether anyone could remember why decimal_point had been forced to 'C' in the first place. Moriyoshi responded, with the news that Ilia Alshanetsky had made the change some time ago due to a problem with handling floats when decimal_point was not '.' Ilia's commit message referred to an elderly bug report, #17079. Hmm.
Derick then proposed that the string to date function strtod() should have a specific implementation for PHP, probably adapted from an existing FreeBSD library. Moriyoshi agreed to this, and referred Derick back to an elderly email from list history. Ilia (offlist) was dubious about the speed of a non-libc function, but agreed to benchmark it following Derick's zend_strtod() implementation. Edin Kadribasic did his part by making the new implementation build on win32.
Short version: PHP doesn't rely on the libc strtod() any more.
TLK: serialize (again)
Francisco M. Marzoa Alonso reported something that he thought might be a serialize() bug, whereby a self-referencing array that had gone through serialization and back would produce a different var_dump() output than its original incarnation. (He didn't say how he'd fallen across this one.)
Andrey Hristov replied that it did indeed sound like a bug, and added a little code of his own that cores the Zend Engine. (He didn't say how he'd fallen across this one either.)
Francisco placed a bug report for both issues, on the assumption that they are one and the same. (They're not.)
Back at the nursery, Andi asked whether anyone had found time to test Sascha's serialize-speeding patch yet. Ilia replied that he'd tested it and found a 10% speed improvement on large arrays. This wasn't quite what Andi was hoping for, and he started talking about that contest again.
Short version: Challenge for Andi: you want it, you organize it!
TLK: Upload progress meter
Klaus wrote in again, this time to highlight an upload progress meter patch and extension that he'd found useful. Was there any intention of including this in PHP source?
Marcus responded, saying that it had come up before but had been forgotten, and that 5.1 would be the first version where such a patch could now be applied. He added that the patch ideally should include script callbacks to make it complete, but changed his mind when he got a moment to think it over. Making the session id available would be nice though - perhaps through the sapi_globals struct. Klaus wondered whether it would be possible for an extension using this to update the session's variables - wouldn't the callback be called at the wrong point for doing this? How useful would the session id actually be to the extension? Marcus pointed out that it would be possible to store this information via SQL.
Curt Zirzow wrote in to say that he already had begun a PECL extension with this functionality - postparser. However it needed more testing and some way of preventing PHP from parsing the data before he could contemplate a release. "And this extension is working WITHOUT callbacks in main/rfc1867.c?" asked Klaus. Curt confirmed this, adding that it would only need a php.ini option in the core to disable parsing. Klaus battled valiantly for his rfc1867.c changes, saying that this would leave the parsing to be done pretty much manually. Implementing the calls there would allow a PECL extension to focus on the progress information and PHP to handle the data. Curt replied that he felt it was the client's responsibility to manage the progress information, and PHP's responsibility to manage such things as authentication and form parsing. Thinking further, he felt it would be better to implement a streams filter:
If we add a ini option for php not to read the stdin on a multipart
post, and rework some of rfc1867.c functions to be accessible from
outside of rfc1867.c's namespace, a custom filter could easily be
written and not have to duplicate the current code.
Meanwhile, Tom Rogers had been busy creating a threadsafe file upload patch against CVS 4.3 HEAD, which, as Wez noted, was a little pointless - new functionality cannot be added into the 4.3 series at this stage. Andi, however, took a look at Tom's code and commented that Zend Engine changes should not be a part of it.
Klaus also submitted his own patch, based on the one at the pdoru site, commenting that it was now rather more generic than a progress meter alone would be, leaving such functionality to be the task of a future PECL extension. He asked for feedback about this patch, but had had none at the time of writing: his patch is therefore sitting in PAT for the time being.
Short version: For the next thrilling installment, read next week's Zend Weekly.
TLK: New overloading feature?
Derrell Lipman had an interesting desire that he wanted to share with the world: he wanted to construct a new object only if a key did not already exist. Thoughts, anyone?
Andrey felt that it would be simpler to use a Pool pattern at the application level than add something like this to PHP internals, but Derrell pointed out that the proposed feature would provide an automatic Singleton capability; the __new() function would always returns its one and only instance, and the application could always use new without worrying about the internal implementation.
Someone named Michael wrote in to say that he didn't think it was "really clean" not to return a new instance with a call to new. He didn't see any advantage over a private constructor and a static getInstance($n) function. Derrell replied that in his view, what was returned was purely the affair of the class concerned:
If the class wants to be a singleton, the user of the class doesn't even need
to know it is getting the same object returned each time it asks for a "new"
one. If the class wants to return a pre-existing object in some cases but a
newly-allocated object in other cases, I believe that's up to the class, not
to the caller. That is a characteristic of the design of the class.
However, he noted that he'd had two negative responses and no positive ones, so suspected that his was not a popular idea. He was right; he had two more negative responses before the end of the thread, one being from Andi, who stated that PHP 5 gives enough tools that the user can do this more readably themselves.
Short version: Enough magic already!
TLK: __call interceptor and static methods
Timm began a discussion that went along fairly similar lines when he asked whether there was a reason that __call shouldn't be invoked for static method calls. Sebastian felt that there wasn't, and that this should be supported. Andi responded, saying that as in most cases method overloading is used for objects and not for classes it didn't seem worth implementing something that could lead to user confusion over context.
Jochem Mass wondered if this potential confusion couldn't be minimized: his idea was that __call should only have the ability to be invoked statically if the class was abstract, and only be invoked on objects if the class was not abstract.
Marcus caught up with his mail at this point and accused Timm of more magic, saying that it would be impossible to tell from inside __call() whether a static or non-static method was intended. You'd end up with items like __static _call() (and friends). However, he added in a postscript, it would be useful in aspect oriented programming.
Stanislav Malyshev, meanwhile, argued that it would not be difficult to implement such a thing; the context issue could be sidestepped with a parameter or by checking for the presence of $this, for example. Marcus pointed out that adding a parameter would be a fairly big BC break; is_null($this) was a workable thing, but would cause some slowdown. Stas also was curious about Marcus's bit of __static magicking; when would Marcus expect that to be called, and why didn't he simply use singleton classes to override a global object's method calls? Marcus answered that it would be called the first time a class was going to be used, and that he personally didn't see the need for it; this was only a theoretical discussion to him.
In the end Stas held the opinion that the whole thing was do-able - it was even possible to avoid the BC breakage - but the question remained, whether it was sane to do it. He wondered "why one wouldn't use a more civilized way of doing things - like appropriate patterns which don't have to require such magic".
Short version: Marcus will write a beginners' guide to aspect oriented programming just as soon as he's finished writing PHP 5.9.*.
NEW: MySQL win32 libraries
MySQL AB took a burden from Edin's back when they released the latest version of MySQL (4.1.7). The MySQL download now includes libraries that will work directly with PHP's extensions. The only reason for including copies of the .dll files (and they are copies, now) in the PHP win32 distribution is that it makes it possible, for those users that need it, to connect to a remote MySQL server.
Until now, those libraries have been lovingly (ok not always lovingly) prepared by php.net volunteers, with the task falling most frequently upon Edin's shoulders. Even when it didn't, Edin - as PHP's official win32 distributor - needed to oversee the quality of the build.
Short version: Edin would like to hug Georg for pressing MySQL AB over this. Thanks!
TLK: PostgreSQL and Boolean values
Sean Chittenden wrote in to complain that, when working with PHP and PostgreSQL, he'd found that the values true and false were returned as 't' and 'f'. He had attempted to fix this within PHP source but had been only partially successful; he presented his patches to show what had been tried.
Michael Sims replied, saying that Boolean values could be viewed as bit fields, which in turn would map to PHP values that would allow truth checking in conditionals. He made the point that, although not all databases have a Boolean return value, they do all share a bit type; but agreed that it would be nice if PHP mapped the PostgreSQL Boolean to its values without having to work around the issue.
Sean confessed that he had moved a large database schema from INT to BOOL before discovering that PHP returns a string that evaluates as true, even for false values. Christian Schneider responded that changing the PostgreSQL mapping (or adding it) would break BC in a big way, and asked why on earth Sean had felt the need to make such a change in the first place. Sean replied that this was a disk-space-saving exercise on his part, and pointed out that there wasn't a single developer he knew that felt the current behaviour was correct.
Daniel Convissor had the final word on the subject when he said that the problem belonged to PostgreSQL rather than to PHP. He used the moment to rhapsodize about the shiny happy future, PDO and the promise of a fix for every bug.
Short version: Is Daniel on drugs?
PAT: make test and rfc1867
Joe Orton having finally got his wicked way --with-libdir, he replaced his entry in the PAT directory with another, much smaller patch for $REPORT_EXIT_STATUS which, in his opinion, no longer behaves correctly.
The only other addition this week is Klaus Reimer's rfc1867 patch, as discussed above.
Short version: Two new items awaiting feedback in the PAT directory.
