On Script-Tutorials.com today there's a new article introducing you to using APC caching in your PHP applications. Their simple example sets up a caching class that handles the dirty work for you.

Today I have another interesting article for PHP. We will talking about caching, and practice of using caching in php. I will make review of APC caching and will show you how you can use APC in PHP. [...] Now people have learned to use the server memory for data storage. RAM much faster than hard disk, and the price of memory falls all the time, so let's use all these advantages of this.

Included in the post is the code for a few different files - the caching class itself that implements the APC functions in PHP and some examples of it in use: saving objects, fetching data from the cache and removing things from the cache.

Stefan Koopmanschap has a quick post to his blog with a handy, not immediately obvious tip for the Symfony users out there - how to remove site-wide stylesheets in a Symfony application so it's not loaded automatically.

Today I encountered a situation I've not encountered before: I have a project-wide stylesheet that should be used for everything, except one specific module that has different (brandable) stylesheets. I created a view.yml for this module with a different stylesheet, but of course the configuration files are merged so it doesn't actually overwrite the main stylesheet file. And this wasn't really what I needed here.

His technique involves a change to the main view.yml configuration file with a special syntax to remove the CSS file with a negation. A snippet is included to illustrate. You can find out more about view configuration in this chapter of the "Definitive Guide to Symfony".

On DZone.com's Web Builder Zone Giorgio Sironi has posted a few methods you can use to help get rid of getters and setters in your OOP PHP applications.

Encapsulation is (not only, but also) about being capable of changing private fields. If you write getters and setters, you introduce a leaky abstraction over private fields, since the names and number of your public methods are influenced coupled to them. They aren't really private anymore:

To show his alternatives, he uses a sample "User" class with a whole list of private properties. There's initially a get/set for the nickname and password values, but he suggests a few replacements:

• passing values in through the constructor
• using the "Information Architect" pattern to have the most responsible method handle the value setting
• the "Double Dispatch" method that uses dependency injection
• using the Command pattern and changesets of data

He also briefly mentions the Command-Query Responsibility Segregation (CQRS) method, but doesn't have any code example to go with it.

Johannes Schluter has a quick new post to his blog today talking about parts of the sqllite extension that will be dropped from the core - the current sqlite_* methods and the pdo_sqlite driver.

The issue there is that this depends on the SQLite 2 library which isn't supported by upstream anymore for a few years. It was a logical step therefore to remove this extension from PHP trunk. The support for the sqlite3 extension and the PDO_sqlite driver (same link as above, read it carefully), which use version 3 of the library, are continued.

The change probably won't be happening in any of the PHP 5.3.x releases but should becoming in PHP 5.4 so, as he advises, you might need to rebuild your database file and change your application to correct things for the changes.

On the Web Builder Zone, Giorgio Sironi has a few suggestions about things that aren't really needed in object-oriented development but seem to have found their way in none the less (most of them are in PHP too).

It is in general true that you should strive for writing code as simple as possible (in length but in complexity too) to obtain an end result specified by a requirement or a user story. If there are two designs for a feature, almost always we would choose the simplest. This article takes a broader view on object-oriented programming, and ask the following question: What are the constructs we don't need in an object-oriented language? What we can take away without hampering our capabilities of building software?

He has a whole list of things that he thinks could be removed - "extra features" that wouldn't cause heartache if dropped including:

• instanceof
• break/continue
• protected subclassing scope
• if (conditional)
• switch (conditional chain)
• public (for fields)

According to this new article from The Register, the C and PHP languages will no longer be taught as a part of the A-Levels computer science course materials.

A-level computer science students will no longer be taught C, C# or PHP from next year following a decision to withdraw the languages by the largest exam board. Schools teaching the Assessment and Qualifications Alliance's (AQA) COMP1 syllabus have been asked to use one of its other approved languages - Java, Pascal/Delphi, Python 2.6, Python 3.1, Visual Basic 6 and VB.Net 2008. The final resits allowing work in C, C# and PHP will be held in June 2011.

According to this document and the AQA, the change is a response to the lack of momentum of some of the other approved languages. They say that the demand for teachers trained with the languages has made PHP and C fall by the wayside to be replaced with things like Delphi or Python.

On the Content with Style blog today Pascal Opitz has made a (very) quick post about how to get PHPUnit up nd running in your MAMP installation.

In order to run my unit tests, I needed to get phpunit running with MAMP. Thanks to the helpful post of Mark Kirby on this, I figured it out.

The key is in changing the interpreter path in one file and removing a bit of code from another to point to the new PHP binary's path. You'll also need to update your PEAR include path to add in the new pear.conf location.

Brian Moon points out a (sometimes annoying) habit of PHP when it comes to newlines - it drops them after the closing tag.

Have you ever noticed that PHP eats the newlines after a closing PHP tag? Not sure what I mean? There is lots on Google about it. [...] So, why does PHP do this? Well, you have to go back 11 years. PHP 3 was emerging. I was just starting to use it for Phorum at the time. There were two reasons.

The first reason was the it, at least in the minds of the developers of the language, "removed all traces of PHP" from the script without any training newlines to show for it. The second case was a bit more valid - because lots of editors at the time required newlines at the end of every line of code. This caused loads of trouble tracking down things like the infamous "Headers already sent" issues (pre-output buffering).

Sameer Borate shows how to turn things around in your application's SQL statement and, instead of selecting the columns you need, showing how to remove the columns you don't need dynamically.

The MySQL SELECT is a ubiquitous statement. You can select rows using the '˜*' operator or by listing the individual column names. But many times you may require using all the columns from a table except a couple of them. For example you may have a table containing twelve columns from which you require only eleven columns.

Sometimes that extra column can contain larger content you might not need or want. He creates a get_column_names and create_statement functions that grab the column names and, based on an "exclude" array, takes out the unwanted records. The array is then looped through and appended back together as the new column list for the select.

After being tasked with some code that was filled with the suppression character (@) all over, Johannes Schluter decided to take matters into his own hands and write an extension to disable it.

That's annoying. So I wrote a simple extension disabling this operator. That helped. I then proposed that extension to pecl, while doing that I found out that Gopal has written a similar extension before. After short discussions we added that extension, using the name scream to pecl and released the extension there.

Documentation for the extension has already been added to the PHP manual for the "Break the Silence" operator. By enabling the setting (either in your php.ini or via an ini_set) turning on "scream_enabled", any use of the suppression operator (@) will be nulled out and all according error messages will be displayed.