My primary point was that procedural code by itself is not necessarily evil. Remember the acronym PEBKAC? Problem Exists Between Keyboard And Chair. Most programming problems can be traced to the programmers themselves.
Few languages have constructs that are truly evil. In C, for example, goto is much maligned. The truth of the matter is that goto, used properly, is not a bad thing. In fact in some cases it can aid in the clarity of the code. Would I use goto? Hell no. I don't even use goto when I am using variations of BASIC. BTW - If you are running Linux like I am and want to see a cool variation of BASIC look at Gambas.
I think that all programmers need to look at and learn OOP. Find out how to write proper objects. Perfect their understanding of the system. Then decide when to use them.
I have written very clean and easy to read procedural PHP that is solid and performs well. Could I have done the same with objects? Absolutely. Objects do have some very worthwhile features that there is no parallel to in the procedural world.
I too learned PHP objects after I did other OOP languages. They were C++, Delphi, Java and then PHP and C#. Having been through these other languages, I found PHP extremely comfortable. It is easy to craft objects in PHP and PHP5 is hands down better than all the versions before it. The overloaded get and set methods rock. I abuse autoload like you wouldn't believe. And the new object features make PHP5 a joy to use.
BTW - In my PHP framework I descend all objects from a base object called TObject - ala Delphi. A TObject has basic error handling, logging, overloaded get and set to implement properties and other features. From there you have TPersistent which is a TObject that is allowed to stream to almost any type of media. I have written custom streams and a TStream object that can stream to just about anything so an objects state can persist between page loads because they are stored to disk files or shared memory, etc.
The properties are handled through overloaded get and set method that verify that the property exists and controls retrieval and assignment. When you define a property in an object you tell it what type it is. The object obeys that type and returns all data in that type. The beauty of that is a $_POST variable that is stored in a property will be forcibly converted to the type that the object supports. If the object is a Float for example, you can then say Property->AsString() and you get a string version. If you say Property->AsCurrency you get a formatted currency string. And before you ask - there is a TI18N object that handles internationalization.
One of the other cool features is crude enums. You can define an enumerated list that is named and has a value. Then you can create an enumerated property and tell it the enum type and it will validate the enumeration whenever there is an assignment into the property.
And that is just the core functionality. The layers above it are cool too. I do device independent rendering of objects so an edit box can spit out HTML (with javascript validators) or XUL or just an XML representation of the object.
I also have an import function that is used to declare your intent to use an object. If you say:
Code: Select all
import('core.TObject');The framework verifies the existence of the object and marks it for late binding. If you use it, good. If you don't it is never even loaded into memory. You can also say
Code: Select all
import('core.*');
import('Renderer.HTML.*');I also use static classes as containers to avoid using globals. So the TApplication static class contains configuration information about the current web application and you never need to instantiate it. It is just there for your use.
So as you can tell. I really like objects but I use them when I feel the time is right.