On the Laravel News blog they've posted a tutorial with some helpful tips for improving your routing in your Laravel-based application.

The Laravel router has a great, well-polished API when you first dive into Laravel as a beginner or newcomer to the framework. What follows is not anything hidden or new, but a few tips that should help you when you’re learning Laravel 5.

The documentation is excellent, and the tips that follow supplement and piece together a few parts that will help you get a quick jumpstart on learning how to use routing in your Laravel applications.

The tips include:

• Custom Namespaces
• Route Macros
• Debugging Routes
• Named Group Routes

Each of the tips include the code needed to implement them and a brief summary of why they're useful.

On the Laravel News site there's a quick tutorial posted showing you how to use named routes in Lumen in writing tests for your application.

When writing tests in Lumen, I recently discovered that the route() helper doesn’t work with tests out-of-the-box.

I prefer to define named routes and make requests against them in my tests. If you follow the Lumen documentation, the typical way that you make a request for a test [of the return of a JSON endpoint results in an error message]. [...] If you inspect things a little closer, you can see the issue: [...] Interestingly, the route doesn’t look quite right, and the router is returning the / route. It looks like the localhost part of the request isn’t being set, and the route isn’t matching. We can fix that by bootstrapping the request as Laravel does.

The post then walks you through the manual process of bootstrapping things so that routes are correctly resolved. This includes changes to the code for the base test case to handle the "boot" and set the path value for the request correctly.

Christian Weiske has posted a quick guide for those still dealing with PHP 4-style constructors in their code and how to upgrade them for PHP 7 (as it's completely deprecated now).

PHP 7 deprecates PHP4-style constructors. In PHP4, class constructor methods had the same name as the class. This was bad when switching base classes; you did not only have to change the class' extends declaration, but also calls to the parent constructor. PHP5 then introduced the generic __construct method name for class constructors, which solved the problem. ?

PHP7 will output a deprecation message when a class with a PHP4-style constructor is loaded

He suggests that a "quick fix" is to just rename the method to __construct and let PHP handle things as expected. However, dependencies in other classes (calling them in a PHP 4 way) could break because of this. He suggests a "real fix" that can be put in place until the remainder of the code is migrated - a method named the same as the old constructor but just calling __construct internally.

In this post to his site Ignace Nyamagana Butera shares a a helpful thing you can do with the regular expression handling in PHP to help make it a bit more clear: embedded comments.

One of the most challenging aspect of using regular expressions is documenting them. More than often you end up with a complex expression that even you as a creator have a hard time documenting. While reading sitepoint recent article around regular expressions I was intrigued that this article did not feature any tips on how to document them. So let’s take a very complex regular expression and see how we could improve its documentation.

He gives an example of a complex regular expression used to parse a URI into its different parts, including an example URI and the resulting parsed array. He points out that, while the regular expression works fine, it's easy to forget what each part does and as it is quite complex. To help remedy this, he includes an example of a commented regular expression (available since PHP 5.2) where you have two options:

• add in named subpatterns with a special < and > notation
• put in literal comments by breaking up the regex into multiple lines and using the hash (#) to mark of the comment at the end of the line

He includes code examples of both of these, resulting in a much clearer, memorable regular expression where the increased number of lines is a good trade-off for clarity.

Mathias Verras has a new post to his site about an idea he calls "named constructors". This method uses static factory methods to simulate the idea of a constructor and initialize the object.

PHP allows only a single constructor per class. That’s rather annoying. We’ll probably never have proper constructor overloading in PHP, but we can at least enjoy some of the benefits. Let’s take a simple Time value object. Which is the best way of instantiating it? The only correct answer is “it depends”.

His example shows the typical constructor creation with variable arguments, but points out that this can get messy quickly. His other method, the factory methods as "constructors", can make for a cleaner interface and makes the class more flexible. They make the object able to be initialized with different types of values and even satisfies the Single Responsibility Principle. He goes through a few examples using his "Time" class, showing how different "constructor" methods can be used to handle inputs ranging from a normal hour/minute format out to a "from minutes since midnight" value.

in a new post to his site Phil Sturgeon talks about a new (old?) proposal to introduce named parameters into PHP.

Named Parameters for PHP is not a new conversation. It's reared its head several times - so much so that the named parameters RFC says: "Since the topic continually gets re-raised, and now PHP has an RFC process, the discussion should be recorded in an RFC (Note this is yet to be done) so the same arguments don't have to be revisited."

He notes the negative attitude that seems to currently be shown in the RFC and has made the offer to rewrite it to be more impartial to the subject at hand. In the comments of the post there's also some feedback about the different syntaxes and varying levels of support for the proposal.

On the PHPClasses.org site today they've posted the latest episode in their "Lately in PHP" podcast series - "Unusual Site Speedup Techniques debate, Named parameters and Annotations".

In this episode, Manuel Lemos and Ernani Joppert discuss several unusual site speedup techniques presented in recent articles of the PHPClasses site blog. They also discuss the (non-)inclusion of new PHP features discussed by PHP core developers like having named parameters in function calls and the support of Java-like annotations in PHP code.

To listen you can either use the in-page player, grab it from iTunes or just download the mp3. Complete show notes and transcript are also included in the post.

In a quick post to hos blog today Stoimen Popov points out a handy feature of the preg_match function in PHP (in PHP 5.2.2 and higher) to be able to name the results of the regular expression match.

In PHP 5.2.2+ you can name the sub patterns returned from preg_match with a specific syntax. [...] This is extremely helpful, when dealing with long patterns. [...] Although it may look difficult to maintain, now you can simply name the sub patterns of preg_match and to call them with their associative array keys. This is more clear when writing code and it's definitely more maintainable.

The key is to use a special syntax as a part of the expression's pattern. This replaces the numeric keys of the matches with values you define, making it simpler to use the results (instead of having to work with numbers that don't match much of anything). Code and expression examples are included.

Jamie Rumbelow has proposed an idea to help simply some of the interactions your CodeIgniter application can have with your databases by using named scopes.

Named scopes are a really powerful feature of models - they allow you to define a clean, concise syntax when performing queries within your models - and best of all, are really easy to utilize in CodeIgniter. The main principle of a named scope is that you create a method that, combined with method chaining, allows you to add details to your query (generally additional WHERE clauses).

He shows two "before and after" examples of multi-line requests condensed down by making a custom model layer with methods containing the commonly used portions of the database calls and returning the "$this" object so it can be used for chaining.

This new post from the Mind Tree blog (at hurricanesoftware.com) asks the question "why do you care about friendly URLs in PHP applications?"

Nice URLs, readable URLs, search-engine-friendly URLs. Different names same deal. [...] Turns out this isn't all that hard with PHP - in fact it can turn into something that's very useful from more than just a readability viewpoint.

He shows how to use mod_rewrite and an .htaccess file to automatically grab the request and map it to the right place. Then, the PHP script looks at the incoming data and pushes the correct page back out to the browser. He's also included some modifications to the original idea that allow for numeric grouping and named groups for rewriting content.