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.

t has been about two weeks since the schedule was published and ticket sales started, but that doesn't mean we haven't done anything in the meantime! There have been a number of updates on both the site and the schedule.

There's five new talks that've been added to the schedule including Paul Matthews' presentation on Solr, Chris Jones talking about high performance PHP apps and David Soria Parra on git. The site updates mainly revolve around the classification of the different sessions - icons added to show skill level and scope of the presentation. There's also an update about the unconfernece and official conference social.

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.

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.

The methods of the class that I [just] mentioned were declared implicitly dynamic, even though it's perfectly possible to call them statically, and the PHP engine won't raise any errors about this process. However, it would be much better to declare these methods explicitly static, thus taking advantage of the functionality offered by the text helper class without having to spawn an instance of it.

They show how to define the methods with the "static" keyword so they can be called outside of the class' scope. Code for the helper class and the code to put it to use.

Welcome to the Call for Papers for the 2009 edition of ZendCon '" The PHP Conference. This year's conference will be held October 19th '" 22nd at the San Jose Convention Center and is being co-presented by S&S Media. It is the largest gathering of the PHP Community and the premier PHP conference, allowing all attendees to mingle with decision makers, core developers, prominent community members, and so many more.

The scope of this year's conference has widened a bit and won't just be about PHP-related topics. Proposals for sessions about things like project lifecycle, frameworks, and performance tuning will also be accepted. There will be five different tracks this year:

• Server/Operations
• Lifecycle Best Practices
• Frameworks
• Real World PHP
• PHP Development Topics

The Call for Papers ends May 31st, so get over and submit your proposal before time runs out!

I've mentioned quite a few times that I am a big fan of Perl programming language. However, most of my programming time these days is spent in PHP. The languages are often similar, with PHP having its roots in Perl, and Perl being such a influence in the world of programming languages. This similarity is often very helpful. However there are a few difference, some of which are obvious and others are not.

His example compares looping (a foreach in both) and how, after the Perl loop the $value variable is no longer accessible. In PHP, however, it's passed back out into the current scope and can be read just like any other variable. While this can be useful, it can also cause headaches when trying to track down elusive bugs.

Today most of the popular programming languages support objects, limiting scope, modularity, passing by value, and sophisticated built-in types. There should be no reason to deliberately expose an object's data to the rest of the code because the language can enforce encapsulation and data hiding.

While not specific to PHP, the post does recommend against them because of one simple reason common to all languages that make them possible - they "break the encapsulation OOP offers". For them, they're like a cheat to get around bad coding practices and are not needed to make a successful application work.

One thing that I think Symfony gets right is that it appears to use partitioned PHP code for its templates, in the spirit of Paul's Savant system.

I noticed in the Symfony demo that there is no separation of scope between variables passed to the template from the controller and local variables in the template. I'd like to see them scoped properly ("$this->products") but I can certainly understand why they did it this way. Using "$this->" in the template everywhere quickly gets messy.

He mentions a few other items he saw as well, including a way to correct the above mentioned problem (two ways - one more single-instance, the other more global).]]> Wed, 20 Feb 2008 07:12:36 -0600 http://www.phpdeveloper.org/news/9659 http://www.phpdeveloper.org/news/9659 Mike Naberezny has posted a few more articles to the "Rails for PHP Developers" website (based on this book) covering some more of the basics.

There's three new tutorials posted:

• Ruby Block Scope - the basics of Ruby block scope, a common point of confusion for PHP developers new to Ruby.
• Variable Arguments - an article that shows two common API patterns found in Rails, variable arguments and option hashes, and how to implement them both in PHP.
• Regular Expressions in Ruby - a useful reference that maps all of the common PHP regular expression functions to the equivalents in Ruby.

Check out the rest of the site for even more great content.