Quote Originally Posted by McGruff
Such as?

OOP - particularly OOP combined with testing - is a much more powerful way to work. I can understand if it looks over-complicated or unecessary on first contact (I thought that when I was starting out) but statements such as above can be very misleading for people who are trying to learn. You don't have to, of course. Php is a bus you can hop on and off anywhere you like. But if you do want to learn to produce the best quality code you possibly can, OOP and testing is the way to go. We'd be selling people short to pretend that procedural is just as good or that it's all just a matter of personal preference.
Examples of awful places to use objects / classes:

- Templates themselves (a "templating" class is usually a good idea, but templates should be pretty much just plain text with some conditional logic thrown in).

- Entry points / boot strapping

- Maintenance scripts


The primary advantages of classes are:

- Modularity (irrelevant since in php you're dealing with individual files...everything is already highly modular)

- Encapsulation (depending on context can be important or not. Generally speaking, it's a lot easier to encapsulate data with classes than without, but php's file-scoped nature means that you have other options).

- Reusability (largely irrelevant to a dynamically typed, interpreted language since you can very easily reuse the same function call or include line for many different types of data without issue)

- Aiding in self-documenting code (ppp methods are more about documentation than actually enforcing anything. Many languages don't actually enforce the constraints at run time, and are only checked at compile time).

That being said, using classes within php generally gives you some advantages, but they aren't the traditional variety:

- Using classes as "namespaces"
- Taking advantage of autoload / class_exists / method_exists / interfaces for some truly dynamic programming.
- Ability to override behavior of many engine internals using SPL.

And, of course, exceptions are tremendously useful, but there's no real reason why an exception has to have anything to do with objects.

Most of the traditional advantages afforded by classes are beneficial in the nasty world of strong, statically typed, compiled languages, but have little impact on the paradigm under which PHP shines.

Well, you can't deny that a code is definatly of better quality if it uses one class to handle let's say all the news functions instead of retyping all of the code everytime you need to do something with news.
Only an extremely novice programmer would do that. Classes don't magically create "reusability". You can get just as much reusability out of a collection of functions as you can out of a class. Do you write an entire regex engine every time you want to do some complex pattern matching on a string? Of course not, you use the (procedural) PCRE functions.

The problem with java in this regard is that primitives aren't objects; if they were, all that functionality could simply be replaced with method calls to number objects, as they are in Ruby. So really, this is a case of the language not being OO enough.
You mean half-assed? There's no real difference between doing 5.sqrt() and sqrt(5), if you look at Math as a namespace (think C++, where you might see something like std::sqrt(5)).

Wrapping functions in a class is useful in PHP because there isn't a namespace, but wrapping the native functions that you're never likely to alter in a class just for the sake of being "more OOP" is a waste of your time. I can say with a fair degree of certainty that you're not going to be re-implementing functions like sqrt, pow, and other basic math routines any time soon.

There's nothing wrong with mixing procedural and OO code. Think about ordinary human language -- some times you say something with the noun first, then the verb, and other times you do the reverse.

dog.poop() makes sense, but

walk(dog) does too.

poop.dog() and dog.walk() aren't things I think anyone is interested in seeing.

yes you can program everything in procedural (but u can also do the same thing in assembly, (or even binary)) but it just gets rediculos!
Yeah, ridiculous, like the Linux Kernel, most (if not all) BSD Kernels, Apache, PHP, most unix tools...

OOP doesn't really make development go any faster or make it any easier to maintain. In many cases (such as C++, which is usually just more trouble than it's worth unless you stick to the basic features), it actually slows development down.

or if you have a fetish for brackets you can program in SCHEME, same thing the program will work but ittl be a waste of your time
If it weren't for the crappy syntax, I'd love to use SCHEME (or lisp) more regularly. Unfortunately about the closest I get to those on a daily basis is javascript (which is basically lisp in C's clothing). Not sure what this has to do with anything, as OOP has nothing to do with functional vs structured programming anyway. Javascript is an OO ("everything is an object"), functional language.

write a multithreaded server and graphical browser in Java then write the same in procedural C and then youll see for yourself
You really have no idea what you're talking about, do you? OOP vs procedural has nothing to do with this. The only real advantage that OOP gives you with regards to threads is that it allows you for convenient storage of your mutexes and the like, but threads are usually a bad idea for most servers anyway (unless you're stuck developing for windows, which managed to completely drop the ball with regards to their process handling and relies on kludges like packing a bunch of individual services into a single process...so much for virtual memory as a safety mechanism!)

except for php5 which as language is quite nice and fast but lacks thousands of packages and classes that make Java and .NET languages so usefull for programmers
I'm pretty sure that the thousands of packages available through PECL and PEAR compare pretty favorably to what's available to Java and .NET programmers...and considering that PHP is the most popular web development language in existence I think it's fair to say that the programmers are getting by quite well with the tools that they have. Nobody's dropping PHP to jump to Java or .NET. They might be jumping to Ruby or one of the recent Python implementations, but anyone who does heavy web development realized long ago that the "P" languages (and those like them) are an infinitely superior tool for this type of task.

You have missed the key feature of OO...
PHP Code:
$table = new WithCrossLinks(new TableDisplay(new DefaultAccount()));

$table = withCrossLinks(tableDisplay(getDefaultAccount());
doSomethingWith($table);

Changing the noun-verb relationship has very little real impact on project development.

OO vs procedural code usually boils down to...

PHP Code:
$obj = new Object();
$obj->doFirstThing();
$obj->doSecondThing();
$obj->doOtherThingWith(new Thing()); 
vs

PHP Code:
$obj Object();
doFirstThing($obj);
doSecondThing($obj);
doOtherThingWith($obj,Thing()); 
I suppose this distinction can help some people, but I haven't really found that it makes a single drop of difference on projects. I'm currently working on an absolutely enormous real time communication system that's almost entirely in C++, and the code that has been written so far is just as bad as the old system which was done in C.

A lot of the OO stuff doesn't work so well in dynamically typed languages for other reasons; for example, most languages have all kinds of funky ways of creating containers. In php you pretty much always just use a map (what they call "array"). You never think about iterators or insertion operators or any of that. It's just not a problem that has to be solved.

The biggest failing of OOP is that it attempts to solve the problem of "large" systems, when in truth large systems should simply be avoided like the plague. You should break up large systems into small, modular, and INDEPENDENT chunks, ideally with each one operating in separate environments. For large scale systems, this is a must anyway, since scalability pretty much mandates that every component of the system operate on a separate piece of hardware. In this model, OOP vs procedural is meaningless.

Yes, as long as they address problems in PHP, not some other language
That hits the nail right on the head. I'm still baffled as to why people try to implement patterns that have no place in PHP in PHP. It's just a waste of time.