According to Felix Geisendorfer's newest post on the Debuggable blog, he thinks that "private and protected methods and properties are one of the most stupid concepts of OOP."

This is a thought I first shared at CakeFest Orlando this year, but could not explain properly at the time.

He illustrates with an example of a protected "balance" variable in a BankAccount class. Sure, it's marked as private but less skilled programmers might not use it that way. He recommends a method without the getters/setters to help make the usage of the variable a bit simpler. He also suggests that using protected/private scoping helps to promote "crappy code" - using them to provide a sort of protection for code that you either don't want getting used or hiding it away so the API can't get at it.

According to this new post on the Typical Programmer blog, using getters and setters in your scripts only adds in a bit of unnecessary coupling and complexity to your scripts that you just don't need.

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.

A little while back, Alan Knowles wondered something that I'm sure has crosses the mind of every PHP developer out there, especially when they came across a particularly bad chunk of code - some people should need to apply for a license before releasing their PHP code out into the wild.

Unlike most of the reviews you get, I was specifically looking at code quality [of the CMSs]. not fuzzy does it look nice!

He looks at a whole list of them including: Tanslucis, Siteman, Pivot, jaf-cms, Guppy, Doop and CutePHP. Unfortunately, most of the news is bad - between badly structured code and mixes of HTML and PHP, there was almost nothing good in any of them.

As Cal Evans and others in the PHP community have pointed out, there's a post on Tim Bray's blog (of Sun Microsystems) with his prediction for PHP for the upcoming year:

The short version: PHP will remain popular but its growth will slow, as people get nervous about its maintainability and security stories.

He does mention the two different stances of this statement - the good side (with low entry level, good applications and speed) and the stance he seems to believe in more - that there are just things about PHP and how its handled that could cause major issues down the line.

Be sure to check out the comments for community views on both sides of the story too.

In light of the massive amounts of PHP frameworks out there, Laura Thomson has posed the question "Do all frameworks suck?"

Choosing a framework to implement your web app is a trade off like any other design decision. Let's focus in on specifics and talk about what the trade off is that you make when you choose a framework. Specifically, I'm talking about MVC frameworks in PHP.

She looks at both sides mentioning the good (code organization, encourages secure coding) and the bad (MVC is defined differently by different people, "More Than One Way to Do It", code bloat). In the end, her recommendation is to look at what you're trying to accomplish and decide first if a framework is for you and your app and, of it is, select the right one for the job.

On the SitePoint PHP blog today, Kevin Yank shares his thoughts in the form of a list for what makes for "good" and "bad" PHP code.

When interviewing a PHP developer candidate for a job at SitePoint, there is one question that I almost always ask, because their answer tells me so much about the kind of programmer they are. Here's the question: "In your mind, what are the differences between good PHP code and bad PHP code?"

Among the items on the list for the good side are things like: structure, consistency, security, and portability. He gives a bit of example code that shows the three levels of "goodness" in a script (using $_GET variables).

In her new blog post today, Ligaya Turmelle has a mini-review/listing of her look into the editor offered by NuSphere - PHPed.

I am normally a vim user when I code but I decided to pop my head out of my cubicle and try something new on the editor front. So I decided to check out NuSphere.

She breaks it out into the two lists - what she likes and what she doesn't like. Included in the positives list were things like an easy learning curve, built in CVS support, and its many customizable features. On the bad list, there were things like inconsistent syntax highlighting, irritation with "code insight" feature, and not having the option to use Firefox as the embedded browser.

Ryan points out a handy tool to help keep even more spammers from making their way to your blogs and posting comments - Bad Behavior.

I love Akismet the spam filter for comments that is built into Wordpress. It's blocked 812 spam comments in a little under 2 months for me. I was content with it, but I grew tiresome that it would even get to my site. Akismet is great for blocking spams that are already to your blog, but there has to be something out there that would block the spammers from coming to your site in the first place.

Luckily there is something like that, it's called Bad Behavior.

Luckily, it's also made for Wordpress, so you can download and install directly with no fuss. He comments that he's already seeing results with even more caught than Akismet was before.

In his latest blog post, Jacob Santos takes a look at a common request PHP developers hit after a while - is it possible to multitask processes/actions in php?

The ability to run two or more commands in parallel is totally sexy, but the Web is a different playing field and it doesn't make complete sense.

PHP loses control, once the output is sent and the connection is closed. Multithreading would probably make sense in streaming, but PHP already handles that for you where it makes sense for the function. Furthermore, mulithreading has its purpose in applications that continue to run and not something that closes and cleans up everything after the last command is issued.

He continues talking more about what multitasking is, a more real life example, the goods, the bads, and some of the issues that can come along with it. Finally, he suggests a feature to be added to the core of PHP - an "internal multitasking mechanism" to help aid these kinds of processes.

For those out there wanting to make the move from PHP4 up to PHP5, Robert Ames has posted a few things to watch out for.

He breaks it down into to categories - the good and the bad. Some of the items on either list include:

• static methods (good)
• E_STRICT (bad)
• random passing by reference gone (good)
• replacing is_a() with instanceof (bad)

He also offers some of his personal suggestions for guidelines for future language updates.