On the TutsPlus.com site they've posted a new tutorial showing you how to register and use service providers in Laravel and how it relates to the service container functionality.

If you've ever come across the Laravel framework, it's highly unlikely that you haven't heard of service containers and service providers. In fact, they're the backbone of the Laravel framework and do all the heavy lifting when you launch an instance of any Laravel application.

In this article, we're going to have a glimpse of what the service container is all about, and following that we'll discuss the service provider in detail. In the course of this article, I'll also demonstrate how to create a custom service provider in Laravel.

The article starts with an overview of the service container and service providers, describing what they are and providing some example code/configuration to clarify the concepts. It then gets into the creation of your own custom service provider. In their case they create a provider that doesn't really do anything but it does help to show how to make it, register it and put it to use in a controller.

Sebastian De Deyne has written up a post to his site spotlighting PHP's list function and showing how it can be used for "array destructuring" and how recent changes in PHP 7.1.x make it more useful.

PHP 7.1 introduced a new syntax for the list() function. I've never really seen too much list() calls in the wild, but it enables you to write some pretty neat stuff.

This post is a primer of list() and it's PHP 7.1 short notation, and an overview of some use cases I've been applying them to.

He starts with a basic introduction to the list function and how it assigns out variables based on an array. He then shows examples of the updates that came with PHP 7.1, allowing you to specify the key from an array to more selectively extract only the value you want. Three "exhibits" are then provided, showing actual use cases for this functionality: basicunpacking examples, creating tuples and handling multiple return values.

Mark Baker has posted a tutorial to his site showing how to use closure binding as an alternative to "use" when calling closures in your PHP application.

As a general rule when creating a Closure, arguments are passed when the function is called, but “use” variables (I’m sure that they have a formal name, but have no idea what it might be, so I just refer to them as “use” variables because they’re passed to the Closure through a “use” clause) are fixed as the value that they already contain when the Closure is defined, and the variables themselves must already exist within that scope

[...] Of course, the drawback of this approach is that when we need to change the price minimum and maximum values for filtering, they’re hard-coded in the callback.

He talks about the limits this imposes on calling the closure (ex: can't easily add addition params) and how the values have to already exist before the closure can be called. He points out that calling the variables by reference can help somewhat but it still comes with some of the same baggage. He then shows how to use object binding for a closure to handle the same kind of "min" and "max" by working around it with a closure bound internally to an object and called via a public method.

On the Exakat blog there's a new post sharing six good practices for "use" in PHP. The "use" keyword has a few different places it is used in PHP (like importing namespaced classes and passing in values to closures).

While reviewing code recently, I realized there are no guidelines for use. Every modern code do use ‘use’ (sic), as importing classes from composer or a framework is the norm. There are now quite a few variations in syntax for importing classes or traits. Although the impact on performance is low, as use is solved out, having a clean approach to ‘use’ is important to keep the code clean and readable. Let’s review what are the six good usage of use.

Each of the six tips they share come with a bit of explanation and code to back them up:

• Do not import unused classes
• Alway use alias
• Place all use at first
• Avoid using the same alias for different classes
• Group use expression for easy reading
• Limit the number of use expression

Some of them could be argued as to whether or not they're a "best practice" but it'd definitely interesting to see some tips for the use of this increasingly common little keyword.

On the QaFoo.com blog they've made a recommendation in their latest post - they suggest that you never use null.

When doing code reviews together with our customers we see a pattern regularly which I consider problematic in multiple regards – the usage of null as a valid property or return value. We can do better than this.

Let's go into common use cases first and then discuss how we can improve the code to make it more resilient against errors and make it simpler to use. Most issues highlighted are especially problematic when others are using your source code. As long as you are the only user (which hopefully is not the case) those patterns might be fine.

They talk about some of the most common uses they see for using null in PHP applications including setters for class properties (injection). They point out that in PHP 7 a missing value on a property would result in a Fatal error and make the functionality harder to test overall. They suggest that all required dependencies be injected on object construction instead, making it easier to know the current state of the object on testing. They also talk some about using null as a return value, how it could make debugging difficult and a solution that could make more sense - throwing an exception instead.

In a recent post to his site Marc Morera discusses the topic of package dependencies in PHP applications. While a lot of the concepts and terms he use are more related to Symfony-based applications, the concepts are good and could apply anywhere.

I’m part of this group of people that consider themselves addicts to open source. [...] want to expose my personal experiences about what I learned over the time by leading an open source project, several small open source bundles and PHP libraries, and I want to do it by explaining how we should take care of our Symfony bundles or PHP component dependencies.

He starts by pointing out that he's talking about framework-agnostic packages and their dependencies here (but his own experience is, again, Symfony-centric). He talks about identifying true dependencies through both use statements and composer.json configurations. He points out that the tricky part comes when your dependencies have dependencies and conflicts that may come up because of these relationships. He also talks about another way to identify dependencies (through adapter use) and package versioning problems. He then gets into talking about Symfony bundle dependencies specifically and links to a tool that can help you map out your required packages. He ends the post with a look at development dependencies and the idea of "trust" in the open source software you use.

Rob Allen's latest post focuses in on something that's been a part of PHP for a while now, back when namespacing was introduced - the "use" keyword. He shares some thoughts, both from others and himself, about whether or not they make code more readable.

I was having a discussion on IRC about use statements and whether they improved code readability or not. [...] Those longer class names make it a little hard to quickly parse what it going on. The [example with "use" statements] is clearly less cluttered, but is at the expense of ambiguity. Exactly what class is User? I would have to go to the top of the file to find out. Should I use aliases? If so, how should I name them?

He went out to Twitter for advice from other PHP developers on the issue too. The feedback from his question came mostly in support of the "use" statements:

• "I think use statements just abstract where the class is coming from. Some people find that useful."
• "I think it's helpful seeing all of the packages used by a class without having to look through the full code."
• "One reason I like them is that I can glance at a file and know dependencies immediately."
• "I do appreciate what you are saying about the indirection use statements introduce."

There's also a bit of talk about "aliasing" with namespaces rather than the full classname, then using the namespace and class name in the code to "minimise ambiguity".

If you're new to the world of PHP frameworks and are having trouble wrapping your head around using one, you should check out this discussion over on Reddit. The poster asks some advice on getting started with frameworks and wether they need one or not.

Hey. I've been learning PHP now for some weeks on a hobby level and I do think it's alot of fun! But, I hear, everywhere people say "Dont reinvent the wheel" and how good frameworks are, but there is some stuff stopping me. [...] And why I just do not keep continue to do my own buisness is becasuse, I hear all this talk about how secure frameworks are, and Im super scared of writing a php website and messing something up. SQL Injections etc etc. So... Do I REALLY need to use a framework, It seem to just complicate things to a whole other level than my current PHP skill.

Responses on the post include a good range of thoughts including:

• "You could instead use a CMS which have elements of a framework built in"
• "I think that Silex is just right for you, and should be familiar enough with your current practice while teaching you the new things you need to know as you go along."
• "Absolutely use a framework, but don't lose that drive to learn how code works."
• "Any framework of repute is making heavy use of design patterns. Having a rudimentary understanding of these will help frameworks make much more sense to you."
• "A framework exists to ease your development [...] A lot of sites use frameworks, but there's nothing stopping you from doing your own thing."
• "If you get confused by larger frameworks and like to have more control over every aspect of your code, it sounds like a micro-framework might be the right choice for you."

With the release of PHP 5.5 came a whole group of new features, including the "yield" keyword for better handling of values in iteration. Blake Gardner has posted a practical example of its use to his site today.

The key to understating the way the yield works verses a normal function is that rather than generating all of your data and returning the final array when it’s done; you yield the value as it’s generated. The state of the generator function is saved after you yield and then its state is restored when called again so the iteration can continue.

He shows a basic use of "yield" in a simple foreach of 1000000 values. In the first example, memory is exhausted and the second yields the values as they come, reducing the overhead significantly. The "range_yield" function returns them as the "for" loop generates them.

Gonzalo Ayuso has a new post today showing how you can use traits in PHP to simulate a kind of multiple inheritance.

Multiple inheritance isn’t allowed in PHP. [It's not] possible with PHP (in Java is not possible either), but today we can do something similar (is not the exactly the same) with Traits. Let me explain that: Instead of classes we can create Traits.

He includes a code example showing the creation of two traits, "Base1" and "Base2", that are implemented (via "use") and the calls to methods on each. He also points out the error condition and message that can come up when there's a conflict in the method names between two or more traits. This is relatively easy to solve with the mapping ability of the "use" statement (code example included for that too).