Eran Galperin has a few misconceptions in web development posted to his blog today (for both front and back-end development).

Here's his list:

• OO code is less performant than procedural code
• The backend is the most important part of development
• Graphical designers are good at user interface design
• The existence of a superior programming language
• XML is more economic than a DB

While the others touch on some topics that could be PHP related, he focuses on it in #1. He points out that sometimes making classes and objects and interfaces and...well, you get the idea...is just too much and that procedural code can be the quick hit you need.

In a new post to his blog, Jacob Santos talks about why object oriented programming just "isn't easy" - including a few of his dislikes about OOP in PHP.

Functional developers have it easy. Damn straight and I wonder why so many developers choose to write functions, when they can opt for more beautiful classes instead. [...] It is easy to get functions right, all you have to do is prefix them and name them properly and you're done.

He notes that most people get OOP up to a certain point - that being the "has-a" and "is-a" relationships - where things start flying over their heads. He expresses his dislike of the way that Singletons are used (or not used) and places some of the blame on the tutorial and book authors out there trying to teach novice programmers with analogies that don't make sense in a codign situation.

Richard Davey takes a look at some of the resource levels used for creating an image with GD in his latest blog entry:

While working on a project I noticed some interesting issues regarding GD images and the amount of memory they take up simply down to where you store them in your PHP script. If you are working with GD a lot then reading this short entry might save you some time / RAM! Update: I've also discovered something very interesting relating to autoloading classes, which again is related to memory allocation.

He was setting up to make a thumbnail from an image and thought to check some benchmarks on memory usage after three different methods:

• normal, procedural code
• putting the image resource into an object array
• storing the image resource in an object variable

In the end, the results were pretty much expected - the procedural (object free) method came in lowest, while the other object-related options had more overhead. It was interesting (as he mentions too) to see the jump between procedural and the object options.

In a new article from Tectonic today, Jason Norwood-Young takes a look at one of the harder things for beginning PHP developers to understand - objects.

Still the practice of using objects in PHP remains a bit of a lost art - you're more likely to find an application with a bunch of functions than objects. PHP just lends itself to function-like thinking.

That doesn't mean that you shouldn't take advantage of the object-oriented (OO) features of PHP. The big question is when. Deciding when to implement a bit of code as an object or as a function is the real trick of object-oriented programming (OOP) in PHP (or as I like to call it, POOP). If you get that right, you can save yourself a lot of time and hassle down the line.

Jason starts off with the differences between OOP and regular, procedural programming, explaining it with a series of reasons/times to choose OOP. Of course, code examples are a must, and a few are included, showing the structure of classes and how to create new objects from them. He explains the PHP5 functionality offered as well, including private/public/protected values and functions.

On his blog today, Quaint has this new post where he looks at one of the things that most developers struggle with at one time or another - "Object Oriented versus Procedural" code.

It was only relatively recent (1,5 years ago) that I was first introduced to the concept of Object Oriented Programming. This was when I first bought Harry Fueck's "PHP Anthology". At first I, like most (beginning) PHP programmers only used to procedural coding, couldn't see the advantage.

This is because the problem with procedural programmers learning OOP is that they tend to put their procedural code into classes/functions. This is however not the point (and the strength) of Object Oriented Programming. Writing good (useful) OOP requires developers to re-design their approach to writing software.

He continues on, talking about how the mindset needs to change for OOP versus procedural, and how code reuability is key. He also gives the example of PEAR for how OOP should be looked at...