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 Evert Pot shows an interesting side effect of working with two objects from the same class: accessing protected properties from one instance to the other.

I realized something odd about accessing protected properties the other day. It's possible in PHP to access protected properties from other objects, as long as they are from the same class. [...] I always thought that protected strictly allows objects to access things from the current inheritence tree, but didn't realize that this also extends to other instances of the same object.

He includes a bit of sample code showing two object instances each being able to access the protected "val" property from the other. He also shows an example of how it works in two different objects, both that derive from a common ancestor. He shares a few other code examples showing this relationship and points out a few places where it could come in handy.

Christian Weiske had an interesting situation pop up in one of his applications around a call to a variable with an interesting name.

Some days ago I saw the following fatal error for the first time in my life:

Fatal error: Cannot access property started with '\o' in file.php

After some debugging, I found out that the source of the error was not some strange BOM or UTF-8 characters in PHP source code files. No, it was a combination of protected class properties, object-to-array casting and automatic template property mappings.

As it turns out, there was a change in how object-to-array casting was done in PHP 5.3 that made this break (related to things appended to private and protected variable names). He includes a bit of sample code to illustrate the problem - a simple class converted from object to array with direct casting. He does point out that it doesn't happen with get_object_vars, though, as that doesn't do the casting, just extraction.

Chris Hartjes has had a few posts about "metatesting" already and in this latest article he takes the series one more step. He looks at moving outside of the current toolset and expanding on them to meet your testing needs.

While PHPUnit is awesome out of the box, it still lacks some tools that are required to do things like test protected class methods or assign values to protected class attributes. Lucky for me we have an awesome testing engineer at Kaplan named Will Parker who has shown me some ways that they have extended PHPUnit itself to make testing certain things easier.

Chris talks about things like testing protected methods (easy thanks to a helper) and checking the value of a class property. The key to both of them lies in using PHP's own Reflection functionality to alter properties on the class objects themselves.

PHPUnit is one of the most widely used unit testing tools for PHP applications. It comes packed with features, some that are commonly used and some not so much. In a new post to his blog today Volker Dusch looks at one specific feature - the "@covers" annotation you can use in your tests' comments to specify which functionality you're actually testing.

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.

Till Klampaeckel has a new post to his blog today looking at the method he's found (through some help from others) to be able to mock out protected methods in his unit tests.

I wrote a couple tests for a small CouchDB access wrapper today. But when I wrote the implementation itself, I realized that my class setup depends on an actual CouchDB server being available and here my journey began.

It was his first experience trying to mock out parts of a class, and he found it a bit difficult to use even after reading this article from Sebastian Bergmann. He ended up, as a first solution, making a "fake" (a term from Ruby testing) that just returned the basic JSON string of an error. Thanks to comments on the post, though, he was able to come up with a more correct solution using getMock() to create a stub and apply an expects() to his "makeRequest" method.

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.

In a quick post to her blog today, Lorna Mitchell talks about an issue with pecl_outh tat came up during her development of a new API. A strange fatal error message was breaking her connection.

I'd gone through all the handshaking steps, got the acces token and was ready to start talking to the service itself. However when I tried to call OAuth::fetch, I got an error message: Fatal error: Uncaught exception 'OAuthException' with message 'Invalid protected resource url, unable to generate signature base string'

As it turns out, the issue was obscure - the address she was connecting to was missing a training slash (http://api.localhost versus http://api.localhost/) and it was causing the OAuth fetch to fail (apparently undocumented). If you're interested in some of the other things that have come up in her work with OAuth on the project, see here.

Vance Lucas has tossed his hat into the ring in the debate about private versus protected scope in PHP projects with this new post to his blog.

The age old private vs protected debate has been re-ignited in the PHP community recently following the decision of Doctrine2 and Symfony2 to make all class methods private until there is a very clear and proven reason to change them to protected or public. The intention is a good one - to ensure they are providing a clear and stable API through intentional and known extension points that they can better test and support. [...] The problem is that this kind of thinking is a slippery slope that kills the spirit of programming.

He suggests that, by limiting the scoping down to private, you're taking away the very thing that gets most people excited about third-party tools - the extensibility. In his opinion, it sends a strong message to other developers that they're "not welcome" to make suggestions or updates to the application/tool.

Stefan Koopmanschap has spoken up in response to some of the comments about OOP design, specifically in using the private scope in your applications. Overall, Stefan agrees and thinks that this access prevents possible extension which goes against the whole point of writing open source software.

I agree with pro-private people that it is important to have a good API design and to use that to protect less experienced developers from making mistakes, however one should never assume that the developers using your libraries, especially Open Source libraries, are less than yourself. [...] I definitely am not in favor of simply opening up the complete library to every developer though. By making a clear decision on which methods are public and which methods are protected you will ensure that people simply implementing your library will use the API that you have taken the time designing.

His does note, however, that there are cases when a private scope is valid - usually when it involves a planned, architected product where it is someone's responsibility to have that access controlled.