Adam Wathan has a new post on his site about a different way of thinking he's coming around to about methods, affordances and abilities.

In one of my current projects, I needed to be able to broadcast email announcements to all of the users in the system. If you've read about enough patterns and principles, there's a decent chance you saw [the line allowing an Announcement to perform the "broadcast" operation] and immediately thought to yourself: "What?! An announcement shouldn't be able to broadcast itself!"

I used to think that too, but over the last few years I've started to think differently.

He talks about "do-er" classes that normally would take in something like an announcement and perform the operation to broadcast it. He suggests that this comes from a misunderstanding about the point of methods: abilities versus things you could do with an object. He goes on to give some examples of double standards with DateTime handling, the complexity it could introduce and how, despite it sounding like an immediate action, the "broadcast" method could just be deferring to a background queue anyway.

Stefan Koopmanschap has a new post today talking about code reviews and introducing the concept for those not familiar with what they are or their usefulness.

Code reviewing is exactly what it sounds like: It is reviewing code written by another developer. There are different ways of doing this, but in the end it all comes down to having at least one other set of eyes checking any code written before it is released. There’s many reasons for doing code reviews. It can be to prevent security issues, to ensure correct performance of your application, to prevent bugs but eventually it all comes down to the more generic term of ensuring the quality of your application.

He goes on to talk about some of the most common ways to do code reviews, either in something a simple as a pull request out to face-to-face discussions as the code is being introduced. He includes some hints on preparing for the review, steps to perform the review, dealing constructively with the comments made and finally the approval. He talks about who should do the reviewing and how they can still be useful even if you work alone or with a QA department.

Mathias Verraes has followed up his previous post about named constructors in PHP with a bit more clarification about when to use static methods (as he did in his "multiple constructor" examples previously).

Some of the reactions to my last blog post on Named Constructors in PHP, originate from the notion that static methods are inherently bad and should never be used. This is rather overgeneralized. Static methods are nothing more than namespaced global functions. Namespacing, I think we can all agree on, is great. As for global functions: We use those all the time. The native functions in PHP form our basic building blocks.

He talks about the main problem with their use, the shared global state, and compares it to a more stateful service. His solution is to either move to a normal object state (that allows for internal tracking) or think more about abstractions and how they relate.

The SitePoint PHP blog has a new article posted showing you how to get started with Underscore, a PHP library ported over from Javascript's popular Underscore.js library with many of the same methods intact.

If you’ve ever used the Backbone framework for JavaScript, you’ll already be familiar with Underscore. Indeed, it’s become incredibly useful for JavaScript developers in general. But did you know that it’s been ported to PHP? [...] Underscore describes itself as a “utility belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects. It’s the tie to go along with jQuery’s tux, and Backbone.js’s suspenders.”

He starts by showing you how to get it installed and some of the basic syntax of the methods it defines (basically replace the period with the double-colon) for both the procedural and OOP handling. He shows examples of a few of the more handy methods it provides including:

• Each
• Pluck
• Minimum and Maximum
• Filter and Reject
• sortBy
• groupBy

...and many more. There's also a bit of talk about templating and extending the library via "mixins".

On NetTuts.com today there's a new tutorial talking about a part of PHP that can be quite powerful but isn't used too often - reflection in PHP. Using Reflection you can get information about your actual code and its elements without having to try to parse it yourself.

Reflection is generally defined as a program’s ability to inspect itself and modify its logic at execution time. In less technical terms, reflection is asking an object to tell you about its properties and methods, and altering those members (even private ones). In this lesson, we’ll dig into how this is accomplished, and when it might prove useful.

They provide a little context around the idea of "reflection" in programming languages and then jump right in with a few sample classes. They set up their "Nettuts", "Manager" and "Editor" classes and show how to use the ReflectionClass functionality to get their structure. The examples show how to get the class' methods, their properties and calling these methods using things like invoke and call_user_func.

Lorna Mitchell has a new post showing nine of the magic methods that are included in PHP by default (like __construct, __get and __set) including a few you may not have used before.

The "magic" methods are ones with special names, starting with two underscores, which denote methods which will be triggered in response to particular PHP events. That might sound slightly automagical but actually it's pretty straightforward, we already saw an example of this in the last post, where we used a constructor - so we'll use this as our first example.

She includes details (and some code samples) for these methods:

• __construct
• __destruct
• __get
• __set
• __call
• __sleep
• __wakeup
• __clone
• __toString

You can find out about these and a few others in this page of the PHP manual.

On Reddit.com there's a recent post questioning the (recently) common saying that PHP developers should avoid static methods when concerned about testability:

I get it: testing is important, and building your codebase in a manner that is easy to test should be a priority. However, sometimes I feel like I have to compromise on the elegance of my code in order to maintain testability. Cases where perhaps a static method makes sense, but end up having to perform some coding acrobatics in order to avoid it. Is this a common challenge, something many developers face and must balance between? Or am I misguided in how frequently static methods can be the most elegant solution (before taking testability into consideration)?

Answers point out a few things - that sometimes, state doesn't matter and static is okay or that they can be used if the instance they return is always exactly the same, never altered.

PHPUnit is one of the most widely used unit testing tools for PHP applications. It comes packed with features, some that are commonly used and some not so much. In a new post to his blog today Volker Dusch looks at one specific feature - the "@covers" annotation you can use in your tests' comments to specify which functionality you're actually testing.

One of the goals of your test suite and the coverage report is to make you trust in your code base and to remove the fear of changing something that needs to be changed. [...] You shouldn't think "Well yes that a 100% but a lot of that just comes from that big integration test and I don't know if the class is really tested!". [...] Thankfully PHPUnit offers a way to drastically increase your confidence in what you actually have tested.

Using the "@covers" annotation on your test method docblocks gives you one more level of confidence in what's being tested and can help make for clearer updating down the road. He also mentions using them to provide extra insight into protected methods in your code and where the test coverage for them really lies.

In his latest tutorial, Alexander Netkachev shows how to, with some of the simple PHP functions, create an event system for your script, complete with callbacks.

The way how events are raised and how listeners are attached on the events is a part of a core in many modern applications. It plays an important role in some enterprise design patterns (MVC, for example).

He starts with the basics of event handling - some of the terms and descriptions of basic functionality that any good event handler would have. He describes the most common setup of an event-interaction relationship. Then, it's on to the code, showing first three different ways to call functions (by name, by variable, and by callback).

He finishes it off with a functional example that responds to a a call to fireEvent (five times) and handles each by calling the function in the callback information (myFunction).

In his latest tutorial, Alexander Netkachev shows how to, with some of the simple PHP functions, create an event system for your script, complete with callbacks.

The way how events are raised and how listeners are attached on the events is a part of a core in many modern applications. It plays an important role in some enterprise design patterns (MVC, for example).

He starts with the basics of event handling - some of the terms and descriptions of basic functionality that any good event handler would have. He describes the most common setup of an event-interaction relationship. Then, it's on to the code, showing first three different ways to call functions (by name, by variable, and by callback).

He finishes it off with a functional example that responds to a a call to fireEvent (five times) and handles each by calling the function in the callback information (myFunction).