Example input array

Expected output array

It looks like most people usually resort to a function that calls itself recursively to build the output array. My two examples below will give the expected output array, but will let PHP take care of the recursion for us.

Iterator, Iterator, Iterator, Iterator

This is my preferred way. OK, sure it creates a hierarchy of objects only to mush the values into an array, but it’s nice and concise. Besides, anyone who knows me knows I’m a fan of the SPL.

Walking the array recursively

This is a more procedural approach, but again it saves us from thinking about the recursion. It uses a closure to build up the array step by step.

Resources

• RecursiveArrayIterator
• RecursiveIteratorIterator
• iterator_to_array()
• Closures
• array_walk_recursive()

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.

Security Enhancements and Fixes in PHP 5.3.2:

• Improved LCG entropy. (Rasmus, Samy Kamkar)
• Fixed safe_mode validation inside tempnam() when the directory path does not end with a /). (Martin Jansen)
• Fixed a possible open_basedir/safe_mode bypass in the session extension identified by Grzegorz Stachowiak. (Ilia)

Key Bug Fixes in PHP 5.3.2 include:

• Added support for SHA-256 and SHA-512 to php’s crypt.
• Added protection for $_SESSION from interrupt corruption and improved “session.save_path” check.
• Fixed bug #51059 (crypt crashes when invalid salt are given).
• Fixed bug #50940 Custom content-length set incorrectly in Apache sapis.
• Fixed bug #50847 (strip_tags() removes all tags greater then 1023 bytes long).
• Fixed bug #50723 (Bug in garbage collector causes crash).
• Fixed bug #50661 (DOMDocument::loadXML does not allow UTF-16).
• Fixed bug #50632 (filter_input() does not return default value if the variable does not exist).
• Fixed bug #50540 (Crash while running ldap_next_reference test cases).
• Fixed bug #49851 (http wrapper breaks on 1024 char long headers).
• Over 60 other bug fixes.

Other nice improvements with this version include an (almost) up-to-date PCRE library (PHP 5.3.2 includes PCRE 8.00 with the latest version being 8.01) for regular expressions and a number of nice improvements to the filter extension both of which I use very regularly.

Do you, dear reader, keep up-to-date with PHP 5.3 (or 5.2) or are you stuck with steadily aging versions due to restrictive hosting providers?

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.

Original Comment (#112314)

Hi Christian, thank you for the article. I would like to share a few comments if I may.

You seem to create the interface (ICrypter) almost without considering why an interface might be necessary. The article skirts around the reasons why an interface might be handy, instead preferring to mention that any class which implements a given interface must adhere to it (other than, “there will be an error!”). It is far outside the realm of a simple blog comment to delve into this subject so I can only suggest that readers take it upon themselves to build their own understanding of interfaces in general and in PHP. There is a lot of great information out there (for a recent insight into the subject, see http://www.brandonsavage.net/why-interfaces-rock/ ).

The article doesn’t state anywhere (though it will be mightily obvious when a reader tries to use the code) that MCrypt is required. Readers, see http://php.net/mcrypt.requirements and http://mcrypt.sourceforge.net/

With regards to the list of “supported algorithms from php.net” it would have been nice to have a source cited for reference. See http://php.net/mcrypt.ciphers

The remarks about Base64 encoding/decoding values seems a little odd. Why would you automatically want to do this? Your argument is that the encrypted value might not be URL-safe but that is only an issue if the encrypted value is being placed in an URL. If you do need to use the encrypted value in an URL then it would make more sent to encode the value only when it needs to be. Base64 is not the only available option for making such a value URL-safe (the functions urlencode and http_build_query to name a few).

It also puzzles me that you use the trim function on the Base64-encoded value since there will not be any whitespace present to be trimmed! The same goes for trimming the decrypted value since there may be important whitespace which really should not be trimmed.

The article itself does not elude to why this helper class might be useful. Your comments state there will be a follow-up article with a more practical demonstration but sure it would have been nice to include a very brief situation and code example where this type of encryption/decryption is of particular benefit.

I guess that is enough writing for a blog comment! Congratulations on publishing your first article on Nettuts+ and I look forward to your next ones.

The above is my comment, copied verbatim (with the links manually added since WordPress didn’t want to do that). Someone probably just missed by comment in the queue, so whether it appears on the Nettuts+ site or not remains to be seen. Either way the full comment is available here for reference.

Edit: between publishing this (at 8:22pm) and now (10:45pm) the comment got approved and is up on the Nettuts+ website. Guess I was just slightly too quick out of the blocks in republishing it here.

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?