In a new post to the Exakat blog they propose an interesting idea: making everything private in your PHP classes with the basic idea being that you can more easily move from a place with more control (private) to less control (protected/public).

It is a good recommendation to make everything private in a class : constants, methods, properties. With private, comes a tighter control on the element : no one from outside may use it, limiting the unwanted impact on the object. Of course, some of the class has to be accessible from the outside, or the object may only be manipulated as a token.

[...] Eventually, when the code matures, it becomes desirable to apply the above principle of encapsulation. This helps keeps the code clean and made of independent components. This is the beginning of a long hunt.

They show how the results look for an Exakat scan of a class and go through each of the results touching on class constants, methods and properties. It also catches when a class property is a "constant" and not modified - or able to be modified - by any means. The post ends with a recommendation to "update your code with your brain" based on the interpretation of the results.

Davey Shafik has a post to his site with some of his thoughts about the "visibility debate" - essentially when the different method/property visibility types make the most sense.

A lot has been said about when to use public/private/protected. Some say that you should never use private, while others say you should never use protected.

About the only thing that people can seem to agree on is that public should be used with caution. That your versioning should be based around your public API, and you have a responsibility to maintain that API. The issue is mainly around the maintenance responsibility of protected vs private. Given that other developers can depend upon protected, it can effectively be considered to have the same overhead as your public API.

He shares some of his own reasoning behind how he uses the different levels in his own code. He touches on each of the different levels, sharing when and how he thinks it should be used to keep a well-structured, consistent API for your library or application.

In his latest post Matthias Noback talks about a problem common to Symfony bundles (and, well, software in general) - dealing with backwards compatibility and breaks that could be introduced with new changes.

With a new bundle release you may want to rename services or parameters, make a service private, change some constructor arguments, change the structure of the bundle configuration, etc. Some of these changes may acually be backwards incompatible changes for the users of that bundle. Luckily, the Symfony DependenyInjection component and Config component both provide you with some options to prevent such backwards compatibility (BC) breaks.

He breaks the post up into a few different kinds of backwards compatibility breaks that could happen and code examples of each:

• Renaming things
• Changing visibility
• Changing values

Each topic also includes methods for preventing issues with older users who maybe aren't using the new features. This includes things like sane default values for new settings, renaming services and creating new extensions for working with new properties.

There's been a few articles posted on various blogs in the PHP community recently about the "most correct" usage of the "private" scope in your PHP applications. As with any feature of just about any language out there, there's people on both sides of the fence. Here's the ones that have weighed in so far:

• Brandon Savage's initial post (an excerpt from his upcoming "Do This, Not That" book)
• A response to this from Anthony Ferrara
• Brandon's own response to comments on his previous article
• This new post from Larry Garfield and some of his experience from the Drupal world

Various topics come up during these posts including static coupling, using interfaces versus inheritance, wrapper classes and developer intent.

In the latest post to his site Andrew Podner takes a quick look at something you don't see too much in PHP applications but is a familiar concept to some coming in to the language from others - using "final" to prevent overrides of the code in your classes.

In a previous post about inheritance, I showed you how to extend a class. One aspect of extending classes that wasn’t fully covered was the idea of overriding a method in a class. You can override a method (function) from the base class by simply redefining the method in the child class. [...] There are times though, when you do not want a method to ever be overridden. There may even be cases where you do not want a class to be extended.

His example shows how to use this "final" keyword on a database class, protecting a method (getRecord) that could potentially break the application if changed. This would then give the developer trying to extend the class an error noting that that method cannot be overridden. One thing to note, if you're going to use "final" in your code, be sure you know what you're doing. More often than not, you probably just want something like "private" or "protected" (see this post for a bit more explanation).

Matthew Weier O'Phinney has a new post to his blog today looking at visibility in OOP in PHP - less about the features the language offers and more about the theory of their use.

I'm a big proponent of object oriented programming. OOP done right helps ease code maintenance and enables code re-use. Starting in PHP, OOP enthusiasts got a whole bunch of new tools, and new tools keep coming into the language for us with each minor release. One feature that has had a huge impact on frameworks and libraries has been available since the earliest PHP 5 versions: visibility.

He covers a bit of the syntax and features of public, private and protected and mentions a keyword not often seen in PHP applications - final. The reason all of this came up was work on annotation support in Zend Framework 2 and some difficulty in integrating it with Doctrine support. The "final" status of the class was part of the problem, and after a a lot of copy & pasting he decided on a different tactic - using its public API to try to work around the problem.

In sum: because the class in question was marked final and had private members, I found myself forced to think critically about what I wanted to accomplish, and then thoroughly understand the public API to see how I might accomplish that task without the ability to extend.

In his recent post Gonzalo Ayuso shares some "strange behavior" he found with method visibility in his recent development:

Normally I feel very comfortable with PHP, but not all is good. There’s some things I don’t like. One is the lack of real annotations and another one is this rare behaviour with visibility within the OO. Let me explain this a little bit.

The problem came up as a part of a recent refactor where a protected method, when called from an object injected into another class, threw an "access" error that it was called from the wrong context. He reported it as a bug but was reminded of how PHP handles exposure - on the class level, not the instance of a class level.

From RubySource.com there's a new post from a confessed developer who moved from PHP to Ruby about PHP's private visibility rules and how they compare to Ruby's.

Alright class - today I’m here to talk about the differences and similarities that PHP and Ruby have when it comes to object properties, methods, and their visibility - how you create variables inside classes, and how you can interact with them.

He compares the private properties in PHP classes to the corresponding handling in Ruby, including the getters and setters to go with them. There's also a look at class visibility settings in Ruby.

From RubySource.com there's a new post from a confessed developer who moved from PHP to Ruby about PHP's private visibility rules and how they compare to Ruby's.

Alright class - today I’m here to talk about the differences and similarities that PHP and Ruby have when it comes to object properties, methods, and their visibility - how you create variables inside classes, and how you can interact with them.

He compares the private properties in PHP classes to the corresponding handling in Ruby, including the getters and setters to go with them. There's also a look at class visibility settings in Ruby.

If you were a fan of the PHP quizes that Mark van der Velden has posted in the past, you'll be happy to know he's come back with part four of the series after a bit of a hiatus.

It has been a while, but here is part 4 of the PHP Quiz series! A few questions to crack your brain about, or perhaps you know them all? Try them and find out! Also do read the idea behind these quizzes, here: The PHP Quiz series

In this quiz he tests your knowledge of class visibility, fluent method handling, class extension, strptime and a tricky "for" loop. Take the quiz and see how you do.