Julien Pauli has posted a look at PHP's closures and how they're actually handled internal to the language.

Back in 2009, when PHP 5.3 got released, a new feature (among many others) were introduced : anonymous functions (also called lambdas or closures). The feature was very expected, as closures have proved their utility through several other languages, particularly javascript that web developers master. [...] Let's see together how Closures have been added to PHP, as usual by turning to the truth : the PHP source code.

He starts at the beginning (a good place to start) and talks about the work that needed to be done on the internals before closures could even be introduced. He walks through the changes made to object handling to make them "callable" and the addition of the "zend_closure" object type. He then gets to the part where "the magic happens" and shows how the userland closure is translated and executed. He ends the post with a look at two other topics: scoping with "$this" and the special handling that was needed for reflection and direct calls to "__invoke".

Michael Dyrynda has a recent post about handling matching and limiting results in Eloquent models in a Larvel-based application.

Say you have a users table with the following fields in it name, email, city, state, zip. You may want to provide fuzzy searching for the name, email, or city and exact matching for the state and zipfields. Why fuzzy matching for only some of the fields? Well, you might want to search for everyone whose name contains Michael or has has an @gmail.com address. Be mindful of the latter; it will expose a large dataset if you're not careful in restricting access to the functionality. You probably wouldn't want to allow it in anything bigger than a proof of concept (which this is!).

He goes through the model process, showing how to set up a simple model with the fields mentioned and make use of query scopes to limit returned results. Code is included showing how to define the "scopeFilter" method in the model and call the "User" model instance with the "filter" method. The example limits the results to only the users with a value in the "name" and "state" field.

In his latest post Allan MacGregor talks about something commonly referred to as Swiss Army Knife Syndrome, a common problem in software development where features and functionality are added "just in case" and aren't needed.

The inspiration for the "Swiss Army Knife Syndrome" came from my frustration in dealing with project managers, clients, and even other developers, that think in too much of a narrow, particular way. I call it the "Swiss Army Knife Syndrome". [...] The term 'Swiss Army Knife' is often used to describe a collection of useful items or tools that are able to perform well in multiple scenarios. While this may be useful, there are risks to be aware of as well.

He points out that not only can software with unnecessary features become cumbersome over time, it can also have the potential for being mostly useless (and unmaintainable). He suggests a few ways the syndrome can show up in your process including scope creep, early optimization and anything that assumes that "more features" is the same as "more value" in the product. In his opinion, software with a clear purpose and that does its job well is more valuable that one packed with features, especially ones no one wants to use.

Vance Lucas has a new post to his site sharing at a project he's been working on, a micro-framework for PHP that takes a functional approach to its structure (and the structure of the apps you can make with it), Bullet.

Bullet is a new PHP micro-framework with a unique functional approach to URL routing that allows for more flexibility and requires less verbosity than the more typical full route+callback approach found in other micro-frameworks. The main problem with most micro-frameworks and even full-stack MVC frameworks that leads to code duplication is that the callback or method executed to perform the action and respond to the URL route lives fully within its own scope. This means that you are forced to repeat a lot of setup code across URL route handlers that load the same resource, authorize it, etc.

He illustrates with an example of a GET/DELETE to the same routes and having to create multiple handlers for each. He restructures this with Bullet and shows how it can nest callbacks inside of handlers to make for simpler routing. It also scopes down requests and gets more fine grained as you nest, making it easier to create reusable handlers (like in other files). If you're interested in finding out more about Bullet and its structure, you can find it in the project's main site.

There's been a few articles posted on various blogs in the PHP community recently about the "most correct" usage of the "private" scope in your PHP applications. As with any feature of just about any language out there, there's people on both sides of the fence. Here's the ones that have weighed in so far:

• Brandon Savage's initial post (an excerpt from his upcoming "Do This, Not That" book)
• A response to this from Anthony Ferrara
• Brandon's own response to comments on his previous article
• This new post from Larry Garfield and some of his experience from the Drupal world

Various topics come up during these posts including static coupling, using interfaces versus inheritance, wrapper classes and developer intent.

In this new post to his blog Rob Allen shows you how to access the view variables from another ViewModel.

Unlike Zend Framework 1, the view layer in Zend Framework 2 separates the variables assigned to each view model. This means that when you are in the layout view script, you don't automatically have access to variables that were assigned the the action's view model and vice versa.

He includes snippets of code with an example controller and a sample view that fetches a value from a child ViewModel instance. He also shows how to access layout and configuration values in the view.

Vance Lucas has tossed his hat into the ring in the debate about private versus protected scope in PHP projects with this new post to his blog.

The age old private vs protected debate has been re-ignited in the PHP community recently following the decision of Doctrine2 and Symfony2 to make all class methods private until there is a very clear and proven reason to change them to protected or public. The intention is a good one - to ensure they are providing a clear and stable API through intentional and known extension points that they can better test and support. [...] The problem is that this kind of thinking is a slippery slope that kills the spirit of programming.

He suggests that, by limiting the scoping down to private, you're taking away the very thing that gets most people excited about third-party tools - the extensibility. In his opinion, it sends a strong message to other developers that they're "not welcome" to make suggestions or updates to the application/tool.

The Dutch PHP Conference has posted an update about the conference today including changes to the schedule and how its represented on the site.

t has been about two weeks since the schedule was published and ticket sales started, but that doesn’t mean we haven’t done anything in the meantime! There have been a number of updates on both the site and the schedule.

There's five new talks that've been added to the schedule including Paul Matthews' presentation on Solr, Chris Jones talking about high performance PHP apps and David Soria Parra on git. The site updates mainly revolve around the classification of the different sessions - icons added to show skill level and scope of the presentation. There's also an update about the unconfernece and official conference social.

Stefan Koopmanschap has spoken up in response to some of the comments about OOP design, specifically in using the private scope in your applications. Overall, Stefan agrees and thinks that this access prevents possible extension which goes against the whole point of writing open source software.

I agree with pro-private people that it is important to have a good API design and to use that to protect less experienced developers from making mistakes, however one should never assume that the developers using your libraries, especially Open Source libraries, are less than yourself. [...] I definitely am not in favor of simply opening up the complete library to every developer though. By making a clear decision on which methods are public and which methods are protected you will ensure that people simply implementing your library will use the API that you have taken the time designing.

His does note, however, that there are cases when a private scope is valid - usually when it involves a planned, architected product where it is someone's responsibility to have that access controlled.

In a new post to his blog Ivo Jansch responds to some of the recent comments about scoping in PHP applications with some thoughts of his own (someone spurred on by the Symfony project saying that "private is evil").

I don't care much about Symfony as I'm not a user, but it turned to a discussion on OO theory when Stefan defended the position by claiming that you 'should have the right to extend a class's methods if it doesn't support the use case you have'.

He also mentions the agreeing opinions of Marco Tabini and Travis Swicegood. Ivo gives an example of a piece of code that uses all three states - public, protected and private - as a use case for his later statements. In his opinion, removing the private/protected scoping from the picture only helps those looking to make it easier to derive information from the class rather than fine-tuning what can be called.

Be sure to read the comments on this one - there's lots of great thoughts from community members in there.