In this post to his site PHP (core) developer Joe Watkins talks about "hacking PHP 7" based on two screencasts he's made on the subject.

Writing extensions is fun, but it's not as fun as hacking PHP. So, we're going to focus on hacking, we're going to imagine that we are introducing some new language feature, by RFC.

Without focusing on the RFC process itself, you need to know which are the relevant parts of PHP you need to change, in order to introduce new language features. You also need to know how PHP 7 works, about each stage of turning text into Zend opcodes.

After talking a bit about some of his thoughts and troubles with screencasting in general he looks at "The Beginning" of PHP's translation from text to functionality: the lexing. He introduces the basic concept around how a lexer works and how it migrates the pieces over to tokens. He then starts in on the parsing of these tokens and, finally, the AST (abstract syntax tree) resulting from the combination of these pieces, executed against a piece of code.

With that out of the way, he starts in about the "hack" - a hipster expression that only works with strings and throws an exception otherwise. He shows the pieces he had to edit to create this new expression and it's matching token/AST node.

Davey Shafik has a post today that talks about an exceptional change to PHP 7.0 and some updates that have been made to provide more of a hierarchy (a different one) that can make them easier to work with.

With PHP 7 errors and exceptions are undergoing major changes. For the first time, the PHP engine will start to emit exceptions instead of standard PHP errors for (previously) fatal, and catchable fatal errors. This means that we can now handle them much more gracefully with try... catch. But with this change, comes a whole new exception hierarchy.

He provides a tree of the error/exception relationships, what they inherit from and who their "children" are. He also talks more in detail about the "error" type exceptions: Error, AssertionError, ParseError and TypeError. He gets into more detail about catchable fatal errors and the userland handling of the Throwable type and extension.

Anthony Ferrara has a new post, following up from his previous look at tries and lexers, continuing along the path to apply what he learned to a HTTP routing system.

In my last post, Tries and Lexers, I talked about an experiment I was doing related to parsing of JavaScript code. By the end of the post I had shifted to wanting to build a HTTP router using the techniques that I learned. Let's continue where we left off...

He starts off with thinking that lexing and parsing the routes out into their respective tokens instead of breaking them up as many do (i.e. splitting on the slashes). He shows the results of this lexing and some parser code to handle these results and turn them into something useful. He did find that the current setup caused a lot of overhead (255 new states per character) so he optimizes the processing with a "default" trie but it was still pretty intensive.

He decided to go a different way at this point, opting for the radix tree structure instead. He includes the implementation of this tree for parsing the routes and his matching lexer updates. Finally he shows how to apply code generation to the results of these changes and how coming back to the "slash splitting" could help...

Anthony Ferrara has an interesting new post to his site talking about tries and lexers, two pieces of a puzzle that are used during script execution. In this case, he's tried his hand at writing a parser which, naturally, lead to needing a lexer.

Lately I have been playing around with a few experimental projects. The current one started when I tried to make a templating engine. Not just an ordinary one, but one that understood the context of a variable so it could encode/escape it properly. [...] So, while working on the templating engine, I needed to build a parser. Well, actually, I needed to build 4 parsers. [...] I decided to hand write this dual-mode parser. It went a lot easier than I expected. In a few hours, I had the prototype built which could fully parse Twig-style syntax (or a subset of it) including a more-or-less standards-compliant HTML parser. [...] But I ran into a problem. I didn't have a lexer...

He starts with a brief description of what a lexer is and provides a simple example of an expression and how it would be parsed into its tokens. He then talks about the trie, a method for "walking" the input and representing the results in a tree structure. He shows a simple implementation of it in PHP, iterating over a set of tokens and the array results it produces. He then takes this and expands it out a bit into a "lex" function that iterates over the string and compiles the found tokens.

From there he comes back to the subject of Javascript, pointing out that it's a lot looser than PHP in how it even just allows numbers to be defined. His testing showed a major issue though - memory consumption. He found that a regular expression method consumed too much and tried compiling out to classes instead (and found it much faster once the process was going).

In the latest post to the SitePoint PHP blog Lukas Smith takes a look at content management systems comparing trees versus facets versus tags in content organization.

For several years I have been interested in content repositories as a key aspect of modern CMS. With “modern”, I mean CMS that are not just “page management systems” but CMS that actually manage content, thereby enabling authors to reuse their content on different devices and even different applications. But when evaluating [prismic.io and contentful.com], I noticed a surprising trend: they do not leverage trees, neither as a native storage concept nor as a visualization concept. Instead, they for the most part rely on flat structures with tagging. My gut feeling was telling me that this was a mistake, especially when managing larger content repositories. At the same time I wondered: “Am I just a dinosaur that is missing the ark?”.

He starts with an introduction to the concepts of trees, facets and tags and starts in on the advantages and disadvantages of each. For each topic he shares a brief summary of what they are and a screenshot showing how they could be visualized. He finishes the post with a "tl;dr;" summarizing the points made for those wanting the basics.

PHPMaster.com has posted their second article in their "data structures" series, this time focusing on trees - a structure for effectively storing related data in an easier to access format.

In a previous article I introduced two basic data structures: stack and queue. The article was well received so I've decided to share data structures in an intermittent on-going series here at PHPMaster. In this entry I'll introduce you to trees, another data structure used in software design and architecture.

He helps you get your head around the concept of trees using the idea of searching data, nothing that a stack or queue aren't exactly the right tools for the job. He talks about the basic concepts behind trees including "leaves" and "root nodes." He includes sample code showing how to make a simple node, insert some child nodes and "walking the tree" to find the information you're looking for.

Rashaud Teague has posted a new tutorial to his blog about data trees and parent/child relationships in PHP applications:

Displaying data in data trees showing parent/child relationships can be important to your application for when users are looking for data. [...] Here I will be showing you (most likely a beginner programmer) how to display data from a database (MySQL) using PHP. In the this example I’m using the data from Maris SimpleDocu, a "simple" documentation system.

His simple table holds data for a series of pages linked by a "parent" key column. Back in the PHP he uses a recursive function to pull in a subset of the data. The end result is output showing the levels of the data, spaced out by dashes.

In this new post to his blog Robert Basic looks at the Zend_Navigation component of the Zend Framework and how it can be used to more correctly handle bad requests.

I wanted to set up routes in such way that when a user requests a page, all requests for non-existing controllers/modules are directed to a specific controller (not the error controller). In other words, if we have controllers IndexController, FooController and PageController, anything but http://example.com/index and http://example.com/foo is directed to the PageController.

Using the Zend_Controller_Router_Route_Regex component he creates an expression that matches anything but the two allowed controllers and pushes them back over to the "page" controller. The new route is put in place via an addRoute call. He also shows how to use the Zend_Navigation component to manage the navigation structure for this application, defining a PHP array of the nested sitemap if the site.

On his Tower of Power blog Daniel Cousineau has written up a look at using a more detailed categorization method than just a parent/child relationship on your data - Tree Traversals.

If the software calls for only 2 levels of categorization (Parent and Child only), a simple nested for loop will suffice. However, software requirements change and you'll soon find yourself up shit creek without a paddle if you need to support 3 or 4 levels of nesting. [...] To those who's training is less formal (most web developers I meet have practical training, not formal), I'll help you out: Tree Traversals (or if you are completely lost, Recursion).

He creates a recursive function that, when passed in a category set with different types in it, can handle each of them and then calls itself again with the new child data. His sample code creates url out of a set of categories.

David has posted an article to the Expirmentalworks.net blog about a task that he and Johannes Schluter have finished up - importing the PHP CVS tree over into Git.

A few month ago Johannes Schluter and I started discussing about GIT and other decentralized version control systems. During our exploration of GIT we thought about importing the PHP CVS tree into git. A few weeks later and a lot of wasted cpu time, we finally managed to provide an inofficial GIT mirror of the PHP CVS repository. It’s provided by Johannes Schluter and mirrored by me.

The post documents the path they followed - using git-cvsimport, parsecvs and a path they needed to make - to finally get the import working without any flaws. You can check out their unofficial repository here (it's updates twice a day from the live CVS).