As Zend Framework 2 is well and truly here, before some of us who are new to it dive right on in, whether you're completely new or, like me, migrating from Zend Framework 1, it's really important to ensure that we understand the core concepts on which it's based. [...] In this, the first part in the series, I'm going to go through what dependency injection (DI) is. However, as there are a number of great posts already available on the topic by some very experienced developers, [...] I'm not going to rehash them.

Instead he extracts out useful tips from posts of a few other sources on ZF2 and dependency injection in general: Matthew Weier O'Phinny, the ZF2 manual, Martin Fowler on dependency injection, Wikipedia and more. He also includes lots of links to more great articles on the subject, both ZF2-specific and for DI iin general.

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.

There has been a trend in the last while for various bits of useful software to have a one-line shell command recommended as the installation method. The usual form of this is to pipe something like curl or wget to some interpreter, be it bash, php, ruby, or some such. [...] This [type of] command takes the output of curl and pipes it straight to bash. I have several issues with this.

His three main points center around the fact that you cannot inspect the code before executing it with this method, that you can't verify the source of the code and that it teaches users bad habits of trusting in "magic commands" like these.

We sometimes conceive of ideas that are arduous to express in code. Like persisting data, or some other uncommon task (sarcasm). It's not difficult, but it takes a lot of keystrokes to write. Being problem solvers, we find it difficult doing this kind of manual labour, especially when machines can do it for us. Still, I would like to take this opportunity to say that typing rocks and solutions that save typing suck.

He talks about the abstraction that frameworks provide (less typing, more work) and and some of the "magic" that comes with them. He gives specific examples of some of his pervious experience with frameworks (including some pains with Symfony2) and how some of the magic he's seen is easy to write but hard to read.

We started the study of PHP magic methods by learning about __get() magic method. [...] PHP is loosely typed language and same variable can be used or referred as string, number or object. The __toString() method is called when the code attempts to treat an object like a string. This function does not accept any arguments and should return a string.

Some quick code is included showing how it works - returning a combined string made from two private class properties when the object ($obj) is echoed out. They also show multiple ways of using the method in both pre- and post-PHP 5.2.

The usage of getter and setter methods instead of public attributes became very popular in the PHP community, and it's going to become the standard coding convention of so many PHP libraries and frameworks. On the other hand many developers - including me too - strongly unrecommend such convention, because of its performance overhead. I wanted to make some performance comparison for years, and today I had time to do that. In this post I would like to show what I found.

He starts with a question every developer asks as their working in their application - why and when should they use getters and setters for their classes. He talks about using them as primary functionality or as fallbacks only when needed. He includes the simple benchmarking script he used to compare accessing/setting public attributes directly and using a getter/setter to do the same. The results aren't very surprising if you think about the "magic" that has to happen for getters and setters to work. See the rest of the post for those numbers.

In my previous post ( PHP Magic Functions ), I discussed about __construct, __destruct, __call and __callStatic. Lets explore a few more magic functions...

In this latest part of the series they look at three functions:

• __set/__get
• __invoke

There are some reserved function names in PHP class starting with __ ( double underscore ). These are __construct, __destruct, __isset, __unset, __call, __callStatic, __sleep, __wakeup, __get, __set, __toString, __set_state, __invoke and __clone. You cannot use these functions to serve your logical purpose but these are meant to be used for providing magic functionality.

They go through some of the above methods and talk about what role they can play in your code and, for some, a brief bit of code to explain how it works. This first part covers __construct/__destruct and __call/__callStatic.

I've been working on a proposal for including service locators and dependency injection containers in Zend Framework 2.0, and one issue I've had is trying to explain the basic concept to developers unfamiliar with the concepts -- or with pre-conceptions that diverge from the use cases I'm proposing.

Using his wife as a sample sounding board, he came up with a restaurant-based analogy to help explain the concept - asking for certain pre-planned things but wanting customizations. He reminds developers that there's not much "magic" to DI. Things are all well defined from the outset and you only have to use it when you want.

PHP version 5.3 introduced a new magic method designed __invoke, this method is called when a script tries to call an object as a function. [...] As php cannot accommodate pseudo-first-class functions, the __invoke method can be used to suppress this language limitation. On other hand you can use this for simpler things as pass a function around.

He includes a simple code example that shows a basic class being called via a variable name - $c('ford') - and the result of its __invoke method being called. He notes that the method, in his opinion, could make for less clean code.