Although I do still feel like getters and setters are to be avoided most of the time, it's hard to tell where to use them and where you shouldn't. [...] While writing the code for [PFZ.nl], I started to notice that each and every class in the system had accessors for most, if not all, protected fields. I've started a discussion with my fellow developers, and this is what I've argued.

He mentions a few things including an article he'd written previously on the topic, some of the points behind OOP programming, encapsulation and accessors and collaborators. He also includes several code examples showing what he considers right and wrong ways to do thing (warning, opinions ahead).

All in all, I don't think accessors are evil per se, but you should only ever use the accessors in cross-layer situations. Don't use accessors to build functionality, but only because you need the value to display and/or save.

GOTO in PHP? Is that possible? It turns out that it is. GOTO is poised to make its official debug in the upcoming 5.3 release of PHP-and the comments are flowing around the Net. We caught up with Sara Golemon, who introduced the construct in PHP, and with Timothy Boronczyk, who made one of the rare level-headed comments about its use, to shed some light on how GOTO will affect the world of PHP.

They look at why GOTO was even on the table for inclusion, how it got started in the PHP code (the target was PHP6) why there's so much controversy over it and how, despite what the naysayers say, it will not be the demise of the language and cause some kind of downward spiral in PHP development.

There are a shed-load of ways to "eval()" code without actually calling the eval() function '" usually done simply to avoid the use of the dreaded "evil()" function, but often times because the system has eval() disabled using "disable_functions" in php.ini. Here is another simple way to avoid eval() without writing out files to the filesystem

His example uses the streams wrapper to natively execute the code from a string variable as a data element, base64 decoded. It's more of a proof-of-concept than anything else, but its an interesting solution to a tough problem to solve at times.

One of the most derided, yet most loved and used patterns is the singleton pattern. Its supporters continually praise its ability to limit instantiation of objects and its opponents continually chastise its tendency to be little more than a glorified global. While programming in many ways boils down to a matter of preference (you can always find someone that agrees with you,) I thought I might as well document my opinion so that those who don't care can have one more thing to ignore.

He starts by (correctly) defining a Singleton and why, because of that definition, they are evil - they become a "global point of access". Why is that such a bad thing, you ask? Mike By their design they mask dependencies, making it harder to do future development and/or maintenance.

I personally do not see very many viable uses for singletons and I know there are many people that agree with me (google evil singletons). It's simplicity seems appealing, but they are incredibly easy to use in a damaging way. This is the danger you risk with any concept that is easy to understand and easy to abuse.

Recently a colleague stated that in theory, caching could be considered 'evil'. Now 'evil' is a very broad term which is used a lot in the IT community, but what does it really mean when we're talking about technical solutions? I asked around, but couldn't find a clear cut definition, so I went searching...

In his search he came across a wide range of definitions, including one mentioning bad design or implying a lack of goals with a summarized meaning of "does harm to your aesthetic and engineering judgment". He applies this to caching and, because of it being a sort of counter-intuitive way to handle content (not just the pull and push), it could be considered slightly evil. Interesting interpretation...

However, as anyone will tell you caching is a very necessary evil. [...] So while it does some minor harm to aesthetic and engineering judgment, the user gets a fast experience, which is really all that matters in the end.

For the past four years, I have put a lot of work into executing a strategic plan that is tangentially connected with our conferences. [...] Instead [of trying to force interaction], I decided to try and slowly steer things in a direction that would have made our conferences closer to a family reunion than a dry business meetup.

He mentions the steps in his "evil plan" (for conference domination?) - community participation, setting the right atmosphere for the exchange of ideas, the oh-so-secret choosing of the speakers and their leadership by example through participation with the speakers and other conference goers.

While I was at php|works I heard a lot of people say how bad of a release 5.2.1 was and that I should stay away from it. Well I didn't take it to seriously at this point, but when I checked what version of PHP we are running on my client project recently it turns out it was 5.2.1.

They were seeing performance issues (database related) so they upgraded to the latest version, 5.2.4, and immediately saw a performance jump of forty to sixty percent and a much lower amount of CPU usage. Upon some further research, he found a certain bug in 5.2.1 that could have been the culprit.

The reason behind using persistent connections is of course reducing number of connects which are rather expensive, even though they are much faster with MySQL than with most other databases.

They go on to talk about:

• issues with the number of active connections that could come up
• the use of too many connections at once
• why persistent connections are disabled in the new mysqli extension