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.

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

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

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