Gonzalo Ayuso has a new post today showing how you can use traits in PHP to simulate a kind of multiple inheritance.

Multiple inheritance isn't allowed in PHP. [It's not] possible with PHP (in Java is not possible either), but today we can do something similar (is not the exactly the same) with Traits. Let me explain that: Instead of classes we can create Traits.

He includes a code example showing the creation of two traits, "Base1" and "Base2", that are implemented (via "use") and the calls to methods on each. He also points out the error condition and message that can come up when there's a conflict in the method names between two or more traits. This is relatively easy to solve with the mapping ability of the "use" statement (code example included for that too).

Josh Adell has a new post today looking at the "powerful combination" of using traits and interfaces in PHP applications. He shows how, despite traits not implementing the interface directly, they can be used to make other classes adhere to them simply by "using" them.

If you're not using interfaces in PHP, you are missing out on a powerful object-oriented programming feature. An interface defines how to interact with a class. By defining an interface and then implementing it, you can guarantee a "contract" for consumers of a class. Interfaces can be used across unrelated classes. And they become even more useful when combined with the new traits feature in PHP 5.4.

He illustrates with a package shipping example and uses an "Addressable" Interface to define the structure for both a Company and Users class. He includes code showing how to implement it in a more traditional "implements" way in a class, but also shows an interesting way to achieve the same thing with traits. Having a trait that follows the interface makes it easy to have a class adhere to the interface just by including the trait (or "using" it).

Kevin Schroeder, in his move towards doing some mobile development, has a new post to his blog about why he's still going to stick with PHP for the backend of this new development work.

I do like working with client/server-like architectures and so I intend to be building apps that have a fair amount of server-side processing to back it up. More details on that to come in the next few months. [...] I have decided that, for the time being, to use PhoneGap for my frontend development. [...] So the question was what to use for the backend development and, to nobody's surprise I presume, PHP is my chosen way to go.

Some of his reasons for the choice include:

• PHP is stupid easy to scale
• It is tied to the web
• (Available) Frameworks
• Tons of blogs
• It integrates with everything

Check out the post for more of his reasons.

For those that either haven't worked much with PHP 5.3 in their applications (or just haven't gotten around to using the feature) Rob Allen has put together an introduction to namespaces to guide you through some first steps and share some example usage.

I know that there are a lot of posts now about namespaces in PHP 5.3. This is mine which is how I learnt how they work. [...] That is, namespaces allow us to: combine libraries with the same classnames, avoid very long classnames and organise our code easily. Note that namespaces do not just affect classes. They also affect functions and constants.

He starts with the basic namespace definition (using the "namespace" keyword), shows how to import another namespace with "use" and the use of the __NAMESPACE__ constant to determine what namespace you're operating in. More information on namespaces can be found in the PHP manual.

On the Query7.com blog, Logan has posted his opinion on how you should be doing your development on sites that are more than just one or two pages - you should be using a framework.

Frameworks should be used when constructing web applications. Any application that involves a database, forms, sessions, cookies or a remote service (such as Twitter or Facebook) will benefit from being powered by a framework. There is no need to use a framework for a website that has only one or two pages, nor for command line utility scripts.

He lists some of the common features frameworks provide including database abstraction, caching, form management, authentication and internationalization. He also includes some of the more general benefits you get from using frameworks like portability, shorter development time, application security, plugins/module support and the enforcement of good coding standards (depends on the framework, obviously).

On the Propel blog there's a recent post talking about how the age of autoloading might be ending and how namespacing could be the next logical step (or could it).

Autoloading in PHP is a great time saver. It lets you write concise scripts without the knowledge of the exact directory structure of the libraries you use. But with the arrival of namespaces in PHP 5.3, and the influence of Java over new generation PHP frameworks, autoloading is changing. In the near future, explicit autoloading will be ubiquitous, but with none of the advantages of the old style autoloading.

He talks about "the old days" when things were included manually through file paths, how that graduated to the SPL autoloading and, most recently, up to namespace autoloading. He shares code samples of how the namespace loading works and how you can abuse it to override current classes/functionality with your own. He points out one interesting correlation though - that the "use" keyword seems a lot like the "require_once" of way back when. He shows how the added verbosity of namespace usage can be a hinderance on frameworks, citing microframeworks specifically and showing one implementation that's non-namespaced next to another that is.

Evert Pot has a quick post about a suggestion mentioned at PHPBenelux related to using namespaces with older code.

If you're running PHP 5.3 and you have to use pesky old code that uses long class prefixes (yea, so, pretty much all PHP code out there), you can still make use of namespace features to shorten them.

He includes a quick example that shows the shift from using the traditional Zend_Controller_Action_Helper_AutoComplete_Abstract to an aliasing with the use/as to just reference it as AutoComplete.

In a new post to his blog Kevin Schroeder talks about a book he's written about some of the stranger things you can do with PHP - You want to do WHAT with PHP?.

You will not find another book on the market like it. Mostly because other PHP authors are not as crazy as I am. [...] In short, if you want a book that goes beyond the practical for the purpose of expanding your mind, this is the book for you. It is not meant to be a "cookbook", pre se. It is meant to, as Einstein put it, stretch your mind so that it does not return to its original shape.

You can see the table of contents [pdf] and a sample chapter [pdf] about working with daemons. Other topics covered include networking/sockets, streams, character encoding, debugging, profiling and good development practices. You can pick up your copy on the MC Press site and have it shipped in early September 2010.

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.

On the php|architect blog there's a recent post from Jayesh Wadhwani asking a question developers all over the world wonder every day - to use a framework or not to (and what's the benefit)?

A framework is usually thought of or defined as an underlying structure. You could imagine a wooden structure, sort of a skeleton when a house is being built. This provides a guide, structure and flow to build the house. A programming framework pretty much does the same thing. A programming framework provides for a structured and disciplined programming which results in a more consistent output from a programming team.

He talks more about some of the things that come with framework use like the utility and "housekeeping" code as well as code you know has been tested and used by other projects successfully (especially with something like the Zend Framework. Remember, though, there's bad that comes with them - a possible steep learning curve and overhead that could be caused by using the tools it gives you badly.