yes, but...

You wrote, "There are also other interesting OOP features like constructor and destructor functions, access protection modifiers, static functions and variables, etc.. but I do not want to go there. This is enough to get you started and migrate your global code to OOP PHP classes."

While I have not contributed any code to this site, I can shed some light on the issue you're raising. I am self-taught in PHP and have no formal programming background. I just recently acquired the book, "PHP Object-Oriented Solutions" by David Powers, and it's proving very helpful to me.

I have struggled with the concepts involved in OOP for a long time now, and so I tended to avoid OOP in my coding. I now understand a little better WHY I was struggling. The way it's presented on most sites (and in many books) is too fragmented to make sense out of it.

In this particular case, you elected to leave out those "interesting" features, but without them it is actually difficult for someone without a programming background to understand the practical ramifications of using global coding and encapsulation. The Powers book includes those ideas, and when I read them, that's when the practical value of encapsulation finally started to make sense to me.

For instance, variable collisions are not the only reason to use OOP. OOP is also very helpful in protecting variables and data. That part always seems to get lost in the discussion when people present the "basics" of OOP in PHP.

It would also be helpful if you discussed in your article the role that public, protected, and private keywords play. In fact, more extensive discussion of how to write functions and then to use them to interact with variables within classes would also be helpful. This is true because people like me who shy away from OOP also tend to shy away from using functions for the same reasons. We might try writing very simple functions, but the more complex they are (and therefore the harder to debug), the more intimidating they become.

Speaking of debugging, that's another very important topic for "basics" understanding of OOP. Because of the "black box" situation, those of us who are used to debugging global procedural scripts can often get lost regarding how to debug an OOP script.

The Powers book does an excellent job of exploring in detail unexpected side effects of working with classes that a procedural code writer would not expect. For instance, consider the role of the underscore character in the formation of a $this -> statement. Before I read Powers, I didn't even realize it was an important feature of the statement!

Another key ingredient missing from your discussion is the scope resolution operator. That one confused me for a long, long time, before I read the Powers book. Trying to find adequate discussion about it on the 'net is like trying to pull teeth, yet so many built-in PHP functions use it in their documentation at php.net. Heck, for a number of years, I didn't even know what it was called! I just knew it as a "double-colon"! Very frustrating for those of us who are not "in the know"! This is yet another reason for a self-taught person like me to shy away from OOP in PHP.

The Powers book (like most such books) does have its flaws, but at least it helped me make more sense of OOP in PHP.

I left those features out of this article because, as you may have noticed, covering all those features is a matter of whole book, not a single article.

The goal of the article is to encourage developers that only know developing PHP using global code, to migrate to OOP based on classes and take advantage of its benefits. That is why I said what was covered in the article was enough to get people started with OOP.

Meaning they can start writing classes now from their migrated global code. It does not mean there is not much more to learn about OOP in PHP.

Okay. Correct me if I'm wrong, but I was under the impression you were trying to explore the reasons why PHP developers aren't programming OOP in greater numbers. I was trying to give you insight as to why the reasons for resistance extend beyond what you wrote in your article.

While I do appreciate the effort and the examples are a step above the usual foo bar and cat vs. dog examples, I tend to agree with Walt that the problem for understanding OOP and why it should be used is lack of information or fragmented information available on the Internet.

I just had a discussion last night with someone who has been programming procedurally with PHP for several years and manages to avoid naming collisions without OOP so this argument is not very convincing to him.

After thinking a while on the subject I think examples of future extendability, separation of business logic, separation of duties, configuration, security, and team development just to name a few are actually more convincing arguments for why OOP is important. Having good real world examples of these things in action and putting them into real world practice will eventually lead to that "Aha! the light comes on!" moment but simply throwing out some basic unreal examples and quoting terms like encapsulation doesn't do enough to make the light come on for those of us who struggle with the concepts.

Sure I am not disagreeing with you that some people need more arguments like the ones you presented to be convinced that OOP is a good thing.

I am just telling that it was outside the scope of this article to cover all possible reasons to explain why OOP is a good thing.

Outside the scope of the article? I'm afraid that belies the last sentence from your article, just before your conclusion: "This is enough to get you started and migrate your global code to OOP PHP classes."

No, it's not enough, and that's the point, for the reasons I discussed.

It seems that the problem is in understanding what the scope of the article is.

I could write an article on a topic that covers matters A, B, C, D, E, F, G. However, I decided to just cover matters A and B just because it is enough to convince that the topic is interesting and presents advantages about following the topic.

I does not mean whoever reads the article should not learn more about matters C, D, E, F, G. On the contrary, the article also mentions those matters but did not enter in details about that because it would take a much longer article and matters A and B are enough for people to start practicing and learning more about the topic.