On Dec 10, 2004, at 3:50 PM, Greg Donald wrote:
On Fri, 10 Dec 2004 10:32:30 -0800 (PST), Richard Lynch <ceo@xxxxxxxxx> wrote:What I do is not use classes.
I agree.
Some of the worst arguments for OO I've heard recently:
"OO programming lets you organize your code better." So what you're saying is that you're not capable of organizing similar functions into files and directories and using include() or require() as needed?
Just because someone thinks using OOP is better doesn't mean they don't think procedural programming is insufficient.
"OO programming lets lots of developers work on the same code base
easier."
Malarkey[1]. The Linux Kernel crew gets along fine with no OO code.
Hundreds of thousands (millions?) of lines of code with thousands of
developers contributing daily. A good revision control system is all you
need.
Yeah, but in the case of the Linux kernel there's no programming language that is both OO and close enough to the metal to program a kernel (other than maybe Forth??). In other words, OOP is not a good option for a kernel. That means that we can't make a judgment as to the relative merits of procedural and object-based programming in kernel development.
"Using OO programming is more efficient" Where are your benchmarks?
Then you have scenarios where you have to come behind coders who think they know OO, but they make poorly designed classes and end up calling lots of functions statically like Object::foo().. which totally defeats the purpose of objects along the way.
Now this certainly isn't an argument against OOP, but bad programming. I don't think anyone is going to argue for bad programming (unless they really like COBOL :-). Also, on the subject of static function calls, in my mind its the closest PHP will ever get to having namespaces and preventing function name collisions.
At all.
And then you run into real life. I'm working at a place right now where they love OO programming. We use Mojavi, PEAR, and Smarty everywhere. I understand OO pretty well I think, and I'm studying the latest Mojavi framework. Hopefully I'll be ahead of the curve on the next project later down the road. I don't really enjoy OO programming and I don't think I'd ever code one of my own projects with it, but I will go grab a PEAR module if it fits my needs. Code re-use may be the only redeeming quality of OO programming, and honestly I can re-use your code from a non-OO include file just as easily.
Code reuse is a major reason for OOP. Obviously you believe that it is no better than old-fashioned procedural programming. I'm not going to disagree with you. Either approach is definitely doable. It is also possible to fuck up either approach.
It just doesn't make sense to instantiate objects for a script whose total execution lifetime is less than a second or two. The overhead just isn't worth it.
This is a good point. There are many times where it doesn't make sense. However, PHP5 is much better at this that PHP4 is.
I think there's a major point missing here. OOP is just another way of providing abstractions to the programmer. Everything above machine-code is an abstraction of some sort and language designers try to provide abstractions which allow programmers to work better. Objects are abstractions, functions are abstractions, even variables are abstractions.
Why do we need abstractions? Because it helps us comprehend systems more easily. If we can only hold some many thoughts in our mind at once, it is advantageous to have high-order (more abstract) ideas, rather than lower-level ideas.
Just my $.02, -ryan
-- http://theryanking.com/blog
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
