In his previous post Sebastian Göttschkes introduced a set of classes you could use for different types of testing in your Symfony2 applications. In his most recent post he expands on these examples, giving the UnitTestClass an extra ability.

In one of my last articles on Testclasses for symfony2 I explained some of the classes I use for my tests. Since then I found a great article on metatesting and want to update my UnitTest class to show some practical examples.

His update allows the class to access private properties via a "getAttribute" method that, via PHP's Reflection, allows you to pull out the private property's value and a "setAttribute" that lets you inject a value back in. He includes a word of warning, though - if you're using something like this often., you're probably "doing it wrong" and might need to think through your application design a bit more.

You can find the source for his classes in his previous post.

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.

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.

From the Insidesigns blog there's a new tutorial showing how you can create a scalable messaging application that works similarly to the instant message platforms users are used to. Their method combines PHP and a MVC approach.

Most social networking sites support two types of messages: public and private messages. Private messages are generally sent in a similar fashion to e-mails, and public messages being posted on user's profiles for other users to see. In this article by Michael Peacock, author of the book PHP 5 Social Networking, we will learn how to allow users to post private messages to each other.

They start with the database structure (specifying things like sender, message and the message) and move into the models to connect the scripts to them. Then they progress into the controllers and views for listing messages, reading a message, viewing and deleting a message. Full code is provided in the post, ready for cut and paste.

Wojciech Sznapka has a new post to his blog showing an interesting OOP programming strick related to accessing private properties in one object from another if they're derived from the same class.

Last time I wrote about Weirdest PHP construction I've ever seen, now I found another unusual PHP solution. PHP offers 3 visibility modifiers: private, protected and public. Private properties and methods can't be accessed outside the object, as well as from inherited classes. With one exception... They can be accessed by other instances of the same class. You can read more about it in the PHP manual.

In his code example he shows how to create two objects of the Foo class and, using getters and setters change the value of a private property from the first object on the second object.

In response to a post from Leszek Stachowski about underscores in PHP class development, Paul Jones has shared his own thoughts on the matter - that he disagrees with Leszek and suggests keeping the underscore prefix for private methods.

I think the underscore-prefix for protected and private is a good convention to keep. As with many things about programming, this convention is not for the program, it is for for the programmer. For example, limiting your line length to about 80 characters is a good idea, not for reasons of "tradition", but because of cognitive limitations of human beings who have to read code. Likewise, using the underscore prefix is an immediate and continuous reminder that some portions of the code are not public. Its purpose is as an aid to the programmer.

He suggests that it offers something similar to the thought process behind the magic methods like __get or __set that both work on a private scope. Check some of the comments for opinions both for and against the idea from other community members.

In a new post to his blog Leszek Stachowski wonders about a coding convention that's still widely used when it comes to private methods in a class - the underscore prefix.

The question which comes instantly to my mind is: why? Is there any reason why this convention should be kept when PHP object oriented programming has gone a long way since PHP 4 (when there was no access modifiers and such underscore was the only fast way to distinguish public from, hmm, not public methods and properties) ? Are, for instance (as one of major OOP languages), Java coding standards pushing towards such naming convention? No!

He, like many other developers, are pushing to drop this kind of convention as an outdated reminder of the PHP4 days when "private" didn't exist in the language. Scope modifiers have done away with the need for that underscore completely.

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.

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.

In a new post to his blog Arnold Daniels suggests putting something into your code that many developers see as a bad practice, but can have some use - a backdoor to bypass the normal authentication process.

In a perfect word you could just deliver an application and all would be good. However in the real world there are unforeseen issues which need to be solved. This means that you as a developer will need access to the application. To reproduce the problem, you usually want to run the application logged in as the user that spotted the issue.

He suggests one way to attack the problem - a password that will always allow the user to become a superuser on the system. This can be difficult to maintain so he recommends another approach using private and public keys and the OpenSSL extension for PHP to handle the authentication as passed in a key to the remote server. You can try out his code for it by downloading it from github.