For those with some time to spare, the subjects were written up as RFCs for discussion on the PHP internals mailing list and were then put up for vote. Those RFC pages are on the PHP wiki under Voting on PHP features (votes) and Release Process (votes).

Both votes are now closed and the tallies are as follows:

Now, on to the point of this post: I voted Nay to both of the RFCs. As you will see (or not, if boredom sets in) neither are the strongest nay in the world but sitting on the fence would be a wasted opportunity.

Voting on PHP features

It is beyond the scope of this post to detail what this RFC covers, go read it now. I’ll still be here when you’ve finished. For those not wanting to bore themselves with the details, or as a reminder for whose who did, this particular topic boils down to: lets have more structured voting for changes to PHP, lets tag mailing list threads with [RFC] and [VOTE] as appropriate, lets move that voting off of the mailing list and on to the wiki, and finally lets put some minimum/guideline timeframes into place for the process.

All of the points are sensible and clearly are favourable to many over what we have (indeed, don’t have) at the moment. But it all seems too lacking in substance and arbitrary for my taste.

Proposal initiation

Ideas for adoption by the community are mostly posted to internals for discussion anyway so the only real change on the discussion side of things is to make an RFC wiki page a mandatory feature. However, requirements of and guidelines for RFC pages is completely glossed over (I’ll assume, because this is a voting RFC). Which proposals require an RFC, every single one? For minor changes, which for practical purposes an RFC might well be overkill, what place is there for a quick show of hands? Is that even to be considered/allowed at all? What place is there for the “scratch an itch” changes that core developers love to slide in to PHP? (Aside: itch scratching is the main reason I got involved!)

Discussion period

The minimum amount of “thinking time” is stipulated as follows:

• 1 week for RFCs that don’t “touch the language”
• 2 weeks for RFCs that do

What exactly constitutes touching is not totally clear, but the example given in the next section is of adding new syntax (compared to, lets say, a new function or class). Why those necessarily need double the amount of thinking time escapes me, as does why any RFC must require a minimum span of time between discussion on the mailing list (and elsewhere) and opening of the vote. What real problems does this period solve? The numbers involved seem completely arbitrary and might as well have said 3 days, or 3 weeks.

Required Majority

Now, I’ll admit to having a love-hate relationship with this particular part of the RFC. I love the idea of everyone having equal say from 15-year veteran of PHP to the brightest sparkly new face, to those who haven’t yet even ventured into the land of PHP internals discussions. As an idea, it gives that warm, fuzzy feeling.

However, I also believe that we’re not all equal. My vote should certainly not carry the same weight as those who have many contributed orders of magnitude more to the language that I have or will, those who, in the past, may have vetoed proposals even with strong “yay” votes. I like the idea of having people who can say, “no, that’s a crap idea and I won’t allow it.” Of course everyone (everyone!) should be encouraged to give their own two pence, but if the likes of Rasmus, Zeev, Andi, or individual extension maintainers are dead against (or dead for) something then that has to mean more than, for example, my vote. Right?

Resurrecting Rejected Proposals

I don’t have much to say on this point. Giving previously rejected proposals another chance sounds fair enough to me, the wants and needs of the community does tend to sway over time. If a rejected proposal is improved enough to be “substantially” changed then it is likely not the same proposal at all so none of the old votes would be on the topic of the new, changed proposal anyway.

Who can vote

Everyone who uses PHP! Oh, no, wait, sorry that’s just impractical. Everyone who has committed code to PHP! Oh, no, wait, sorry that’s just too few. Hmm, everyone who has written a framework! *sideways glare*

I still have no idea of who we’re voting for being allowed to vote. My conclusion is: whoever can be bothered signing up for a wiki account and following the required “hey, I’m not a robot” procedure.

Conclusion

The aim of this RFC is to put in place a process to replace the old “+1″ emails on the internals list. That system had its problems, mostly in the shape of finding all of the votes to tally them! In the same way, I think that the proposed system also has problems which the RFC does not even attempt to provide direction or solutions, and also has solutions where there aren’t problems.

Release Process

As with the other RFC, I really do kind of agree with the sentiment of this proposal; it would be nice to have neat, tidy, regular releases (to know an addition will be publicly available within a year would be a nice incentive). My main disagreement with this RFC is that we were expected to give a single yes/no vote on… well, multiple things.

Releases Cycle

I’m no expert on release cycles in open source projects, so comparison with what works elsewhere is beyond me. The proposed yearly release cycle (for major versions) with 3-year lifetime seems super-duper short for PHP, as does a monthly (or less) cycle for minor releases, but if folks think it will work great then lets run with it. I do worry however about having too many plates to keep spinning. One of the illustrations shows 5 separate branches being actively developed concurrently. I don’t know if that is a lot, or a drop in the ocean compared to other projects, but tackling just a couple of branches at any one time seems more than enough work for PHP at the moment.

Feature selection and development

There is not much to say for this section. The idea is that RFCs and wiki votes is the way forward. However it does add to the list of questions that we’re supposed to provide a single vote for/against. The topic of who can vote should have been decided during discussion (and a previous vote!), and the proposal updated to reflect that. We can’t say “yes” to, “Who will be allowed to vote?”

RMs Role

Apparently, they won’t be allowed to decided which non-bug-fix changes get to go into a release. So much for, “hey, that’s still super-buggy lets keep working on it for a while.” I believe a release manager should have the final say as to whether any individual feature is ready to go into a release. The RFC doesn’t make this clear, but it certainly sounds like once something has been committed, it will be in the next release; at least, there is no mention of anyone (community decision or otherwise) agreeing whether a feature is ready or not.

Release managers selection

The idea here is that pairs should put themselves forward as RMs, and we should vote them in. Are there really so many pushing to become RMs? I have not been around the core for too long but I’ve certainly not seen an over-abundance of volunteers for the role. This particular proposal sounds like needless faff.

Feature(s) preview release, solving the experimental features

Harking back to an earlier section, the aim here is to provide “feature preview” releases so that new features can get some more thorough real-life testing/use by brave folks before hitting a normal release. As with above, there is no scope for “whoa, this really isn’t ready yet” or even “what were we thinking?!” whatsoever. On the plus side, more testing is a very good thing.

Security Management

This section gets a big thumbs up from me, even though not being able to read the security-related bugs is a personal annoyance. How this relates to the rest of the RFC in any way is questionable, but I like it.

Conclusion

As with the other RFC, the general theme is certainly something I will support. However, the devil is in the details and in this case so is my disagreement with what is, and isn’t, being put on the table here.

And finally

The primary reason for this post is not to start some long-winded discussion on the above, merely to document my varied thoughts. If any discussion does come of it, then that’s great but I will probably run away and hide if people start getting all outspoken.

Favourite changes

• Paths containing NULL (like /some/path\0foo.txt) are now considered invalid.
• Added follow_location (enabled by default) option for the http stream support.
• Implemented FR #50692, not uploaded files don’t count towards max_file_uploads limit. As a side improvement, temporary files are not opened for empty uploads and, in debug mode, 0-length uploads.
• Fixed bug #53409 (sleep() returns NULL on Windows).
• Fixed covariance of return-by-ref constraints.
• Fixed bug #50579 (RegexIterator::REPLACE doesn’t work).
• Upgraded bundled PCRE to version 8.10.
• Upgraded bundled Sqlite3 to version 3.7.3.

Also, 5.2.15 was released yesterday, which marks the end of support for PHP 5.2.

For full information see the 5.3.4 and 5.2.15 announcements on php.net.

• Added support for copy to/from array/file for pdo_pgsql extension. (Denis Gasparin, Ilia)
• Changed namespaced classes so that the ctor can only be named __construct now. (Stas)
• Fixed bug #51590 (JSON_ERROR_UTF8 is undefined). (Felipe)
• Fixed bug #49576 (FILTER_VALIDATE_EMAIL filter needs updating) (Rasmus)
• Fixed bug #48361 (SplFileInfo::getPathInfo should return the parent dir). (Etienne)
• And well over a hundred other bug and security fixes

The change to constructors in namespaced classes has already been the subject of “why doesn’t this work” questions. With 5.3.3 you cannot define class constructors like below.

Instead, you need to be using the right and proper __construct method. Note that this only applies to namespaced classes, so old code can continue (if they like) using the class-name-based constructor. This really only affects the (few?) folks who might be making use of, or adapting their old code to use, namespaces yet still keeping the old style of naming the constructor method.

Go, play!

Happy birthday, PHP!

* See Announce: Personal Home Page Tools (PHP Tools) Options (8th June 1995)

Elsewhere

• 15 years of PHP from Johannes Schlüter

Intro to the glob function

To quote the succinct description on the PHP manual page for glob:

The glob() function searches for all the pathnames matching pattern according to the rules used by the libc glob() function, which is similar to the rules used by common shells.
http://php.net/glob

What’s in a pattern?

Most people who have already encountered glob know to make use of the * metacharacter to match some characters, and those digging a little deeper often discover that discrete alternatives can be globbed with braces (e.g. image.{gif,jpg,png}). However, there are more special characters and sequences that can be used to be more (or less, if we want) specific about what to find.

Aside: please do not make the mistake of thinking that glob patterns are regular expressions, they’re just not. If you do want to use regular expressions to find paths/files then you are invited to use SPL’s RegexIterator, which allows filtering of an Iterator based on a PCRE regex, in conjunction with a DirectoryIterator or FilesystemIterator (there are recursive flavours of the Regex- and DirectoryIterator if you need to delve into folders). For those SPL-ly inclined, also note the GlobIterator which combines the goodness of globbing with iteration. If that made entirely no sense, please read on! Globs are much less verbose…

So, here are the special doohickeys (technical term!) that we can use with glob:

* (an asterisk)

Matches zero of more characters.

?

Matches exactly any one character.

[...]

Matches one character from a group. A group can be a list of characters, e.g. [afkp], or a range of characters, e.g. [a-g] which is the same as [abcdefg].

[!...]

Matches any single character not in the group. [!a-zA-Z0-9] matches any character that is not alphanumeric.

\

Escapes the next character. For special characters, this causes them to not be treated as special. For example, \[ matches a literal [. If flags includes GLOB_NOESCAPE, this quoting is disabled and \ is handled as a simple character.

Globbingly good glob examples

Here are a few examples of what globs might look like alongside a brief description of the intended behaviour: if you have any suggestions please do make them in the comments as I'm running short on inspiration!

Well there we go, I’ve said what I came here to say so all that remains to be done is give some link love to those two recent articles that prompted me to dust off this draft and click the “publish” button.

With thanks

1. php|architect’s Putting glob() to the test focuses on execution times of glob and other techniques of getting a list of files.
2. Marcus Schumann’s Loop Through Folders with PHP’s Glob() article on Nettuts+ gives a brief introduction for those who might not have been introduced to glob.

The (currently undocumentednow documented³) DOMXPath::registerPHPFunctions method is available as of PHP 5.3.0 (it was added to the code base back in December 2006) and allows the use of PHP functions (and static methods) within XPath queries to complement the normal set of XPath functions².

Description

void DOMXPath::registerPHPFunctions ([ string|array $restrict] )

Enables the use of PHP functions as XPath functions.

Parameters

restrict

Use this parameter to only allow certain functions to be called from XPath; it can be either a string (a function name) or an array of function names.

Return Values

No value is returned.

Examples

Note: The following examples load a sample XML document called book.xml with the following contents:

Example #1: Call a PHP function in XPath with php:functionString

This example demonstrates the basic use of DOMXPath::registerPHPFunctions by replicating the substring XPath function. The first thing that needs to be done is to register the php namespace with the associated URI http://php.net/xpath. Don’t question it, it just needs to be done!

Next, we call DOMXPath::registerPHPFunctions on our object. If no arguments are used, as in this example, then the range of functions allowed to be called is not restricted—you can call any⁴ function from XPath. I would always advise restricting the functions which can be called, see example 2.

Within our XPath query, we use php:functionString which allows us to name a function and provide some parameters (or indeed, no parameters) to be passed to that function. There are two flavours which can be used here: php:functionString which passes an XML node/attribute as a string and php:function (see example 3) which passes an array of XML node/attribute objects (in DOMElement / DOMAttr / etc. form) to the function . In this example the PHP function substr is called, passing along the book’s title (in string form), an offset of 0 and length of 3. This returns the first 3 characters of the book’s title which is then compared to the string PHP in order to filter our list of books down to those having titles starting with PHP.

The example will output something like:

Example #2: Restricting the functions available to XPath

To restrict the functions made available to XPath, provide either a string containing the name of the single function that you wish to allow or an array of strings containing function names as the restrict parameter (note: static methods can also be used, e.g. “Classname::method“). If functions were added with restrict and a function is called in XPath which is not one of them, an E_WARNING will be raised stating Not allowed to call handler ‘function()’ (where function is the name of the function that cannot be called).

The example will output something like:

Example #3: Passing DOM objects using php:function

Up to now, the examples have both used php:functionString. As mentioned above, instead of passing a string value to the PHP function it is possible to pass along an array of DOM* objects to manipulate them as you please by using php:function.

The example will output something like:

Summary

Just to quickly summarise everything, here is a quick run-down. In PHP, make sure to register the php namespace (with the URI http://php.net/xpath) and then register your PHP functions (whether core, extensions or user-defined) or static methods with DOMXPath::registerPHPFunctions. In XPath, use php:functionString or php:function to call the PHP function.

If you have made use of this feature, or want to know more, then do feel free to comment. Thanks for reading.

Footnotes

1. http://php.net/dom
2. http://schlitt.info/opensource/blog/0704_xpath.html
3. The documentation page, when it gets written, will beis available at http://php.net/domxpath.registerphpfunctions
4. In truth, some functions are not suitable such as those that return non-scalar values (and cannot be cast to one) which XPath will not understand.

On the plus side, for those who have yet to take the plunge into using PHP 5.3, this iterator has been part of the core of PHP as of 5.1.0 so there is a much greater chance of actually being able to use it right now. Bear in mind that the SPL is supposed to work together with its component parts so if iterators are a foreign concept, some of this post might be a little unclear but it is not the purpose of this post to outline iterators in PHP.

As eluded to above, the InfiniteIterator comes in useful when you have an existing Iterator (anything that implements that interface; a directory listing (DirectoryIterator), a file (SplFileObject), an array (with ArrayIterator), and so on) and wish to iterate over its contents again and again.

An InfiniteIterator Example

Here is a basic example that I wrote for the documentation. Note that a LimitIterator is used to restrict the values which are iterated over (otherwise the loop would go on forever!).

This example outputs something along the lines of:

Can you think of any more useful instances where the InfiniteIterator might come in useful?

Here’s the summary

• Just because it’s not the latest and greatest version, it doesn’t mean it’s not good
• Just because you don’t understand something, it doesn’t mean you shouldn’t embrace it
• There’s nothing stronger than a bond between those who care
• It takes all kinds to make the ‘verse go ’round
• Use only what you need
• A good team is nothing without good leaders

Anonymous Functions

Put plainly, an anonymous function is a function without a name. That’s all, there’s nothing magic or particularly technical about it. There are a few ways to create an anonymous function in PHP; up until PHP 5.3 came around the usual way was to use create_function (see fig. 1) which takes a couple of arguments as strings and spits out a function, in PHP 5.3 we’re allowed to create anonymous functions looking much more like normal function definitions (see fig. 2).

Fig. 1: Anonymous function with create_function

Fig 2: Anonymous function as of PHP 5.3

I hope you’ll agree that the latter is a much nicer way (visually) of defining an anonymous function, quite apart from the more logical and performance-related (see comment #4) aspects of using it.

Closures

A closure is a (anonymous) function that is aware of its context. For all intents and purposes, think of them being anonymous functions which know about some variables which weren’t defined within them. In geeky language, they are functions which close over (hence “closure”) free variables, the latter being variables which are not local nor arguments to the function. It is easier to see with an example, I think.

Without Closure

Lets say that we need a function to add three to a number (overly basic, I know). That’s easy.

Now if we wanted another function to behave similarly but instead it should add 4 to the supplied number, we could just as easily create a new anonymous function to do the job.

If, however, you wanted to do that for a series of different additions then things could get very repetitive, very quickly! If only we could dynamically create an anonymous function to do what we wanted: enter the closure.

With Closure

We can define an anonymous function (it needn’t be anonymous but lets keep on theme) which returns anonymous function based on arguments supplied to it. Remember our definition of a closure above, specifically making use of ‘free’ variables, that is what our $value_to_add is in the example below.

A more practical example

As fun as silly adding examples are, there will be undoubtedly someone who has been reading everything above (good job getting this far!) and cannot see a practical use for all of this. Since le Tour de France is on, lets have a play on words and have an example on cycling (over a series of values).

Cycling with Closures

That example would provide the following output:

Well, it’s a little bit more practical anyway! Have you been playing with closures and/or anonymous functions too?

Go download and play with the new features available such as namespaces, LSB, anonymous functions and closures along with many more bug fixes, additions and improvements.

My favourite addition at the moment is the improvements made to the DateTime extension with new classes such as DatePeriod (for iterating over dates/times) and DateInterval and additions to the DateTime class such as DateTime::createFromFormat and DateTime::add (and sub).

The anonymous functions will also be very useful where one might previously use create_function (or a normal non-anonymous function) in particular for callbacks to other functions/methods.

So, download it and have an explore.