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.

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.

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.

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.

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).

Are you interested in having at your disposal a quick reference for working with the "DirectoryIterator" class that comes with PHP 5? Then this might be the article that you've been waiting for! Welcome to the second tutorial of the series "A Close Look at the DirectoryIterator Class in PHP 5." Over the course of this set of installments, you'll find complete coverage of the most important methods bundled with this class, and learn how to take advantage of their excellent functionality.

They cover even more functions in this part:

• rewind, current, valid
• getFileName, isFile
• getMTime, getATime, getCTime
• getPath, getPathName

Continuing our PHP functions article, we move on to creating classes. Let me say right at the start that you can write perfectly effective and useful PHP code without creating classes or going into object oriented programming. Object oriented programming can be very powerful and PHP programmers are increasingly taking advantage of these capabilities, which have been greatly expanded since PHP4.

They start with the creation of a simple class - a human class with two $legs and two $arms. They show a simple display of this data and add another attribute to the class, one for hair color. They then capture the output they've been creating inside a function, report, and show how to execute it. Finally, they show how to use the special function that runs when the object is created - the constructor.

I must say that the "mysqli" extension offers an impressive set of features, which can be implemented right from the very beginning. However, and speaking of its cool features, in the next few lines, I'm going to show you a few more. Over the course of this last tutorial, I'll be covering some other methods and properties, mainly aimed at finding the IDs after inserting new rows, and obtaining information about specific table fields.

They touch on the fetch_array, data_seek, fetch_assoc, fetch_field, and fetch_seek functions, giving examples and other assicated properties along the way.