In a new post to his site Pascal Martin shares some thoughts about why INI directives are evil, mostly in how they could be used to enable/disable major pieces of functionality in the PHP language.

A few times, while evolutions were discussed for PHP 7, someone suggested a new feature could be optional, depending on an INI configuration directive — the idea being each user could then enable it or not.

Still, the idea of directives that could change, sometimes deeply, the behavior of a programming language… It scares me!

He goes back in time a bit to talk about a feature like this that was once a part of the language (happily removed now): "magic quotes". He points out that, while the intent was to provide security to submitted data, the results were disastrous if it was moved to another server without the setting enabled. He also points out some of the steps that have to be taken when a new directive controlling a major feature is introduced - even worse if you're creating a product to run on other peoples' servers.

In any case, before suggesting "but they could allow us to enable or not this feature with a simple INI directive" for ideas as critical as a weak or strict typing mechanism, ask yourself: do you really want two languages with very distinct behaviors, and applications and libraries that work only on some combinations of configuration values?

Derick Rethans has shared some of his thoughts on how to not be evil when it comes to making changes in languages like PHP. He suggests that any backwards compatibility break should be treated with the weight it deserves and not just thrust upon users.

This is a repost of an email I sent to PHP internals as a reply to: "And since you're targetting[sic] the next major release, BC isn't an issue." This sort of blanket statements that "Backwards Compatibility is not an issue" with a new major version is extremely unwarranted. Extreme care should be taken when deciding to break Backwards Compatibility. It should not be "oh we have a major new version so we can break all the things"

He talks about the two kinds of backwards compatibility breaks: obvious things where features are removed or changed in a major way and subtle changes in how the underlying code for PHP works ("subtle changes"). He points out that most of the frustrations from users comes from the second type, making for a slower adoption rate and maybe not even adopting at all.

Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so.

In a new post Berry Langerak wonders if the getters and setters commonly used in PHP applications are a necessary evil and if they should be used at all.

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.

From Marco Tabini (on the php|architect blog) there's his look at GOTO, a new feature to be included in PHP 5.3, and whether its a bad/evil thing have in PHP or not. He talks with two developers about its impact.

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.

Davey Shafik has a helpful hint for avoiding one of the worst functions to use in PHP - eval.

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.

Mike Lively has posted a few choice words about one of the most popular and most used design patterns out there - the Singleton.

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.

On the Ibuildings blog there's a new post that looks at the "evils" of a crucial part of many web applications - caching.

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.

In the wake of this year's php|tek conference, Marco Tabini has unveiled his secrets to the "master conference evil plan" that he and the php|architect crew have been putting in to action for their conferences:

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.

Felix Geisendorfer has a reminder from developers out there - "PHP 5.2.1 was an evil release":

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.

Felix Geisendorfer has a reminder from developers out there - "PHP 5.2.1 was an evil release":

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.