"Powerful" is an opinion, and you have repeated that mantra WAY too many times to have an open mind to people of the opposite opinion.McGruff wrote:It's a great thing about php that you can jump right in and start learning to code but programming well means using the most powerful tools available: OOP and unit testing.
Personally, I think unit testing is about 300x more powerful/useful than OOP - and no, one does not mandate the other.
The arrogance here is strong - the implication is that I neither have experience, nor have I done any design. On the contrary, I've programmed for over a decade, and have coded in PHP for 3 years. I've maintained over 100,000 lines of code in that time, deployed on hundreds of sites, serving tens of thousands of users - so I would say that I've gone more than a few steps beyond embedded echo calls.McGruff wrote: Once you get a few steps beyond embedded echo calls, you have to start thinking about script design.
The sad part is that you cant see that someone with knowledge, intelligence and experience could have a different opinion about OOP.
If close-minded opinions are one-dimensional, being open to people having different opinions is the ninth-dimensional string theory.McGruff wrote: If programming in the global scope is one-dimensional, using functions adds a second dimension and OOP is 3D.
OOP can be useful (or a hinderance).
OOP can make things easier (or harder!) to maintain.
OOP can make things faster (or slower!) depending on the programmer.
OOP, like procedural code, can be anything from horrible to fantastic.
Its very nature does not bestow upon it the magical world-solving abilities it would need to have to justify your proselytizing it repeatedly.
My experience says otherwise, as does millions of applications (that still run) that were written before OOP was a popular concept.McGruff wrote: I've often heard people say that using functions / structural programming is an alternative to OOP but, unless you severely restrict the problems under consideration to very simple tasks, I don't think this holds up.
Careful choice of terms there. My opinion of it is a bit different: "OOP is complicated - until you understand it, and then its a little more complicated than procedural code".McGruff wrote: The big problem for budding php-ers is that, at first glance, OOP looks unecessarily complicated and "inefficient".
To be clear - that which requires understanding is by definition more complicated.McGruff wrote: There's also quite a steep learning curve to get over before you can begin to appreciate why this is not true.
And much like a hammer doesnt do much good for a screw, it is deeply disgusting to hear it parroted as the swiss army knife solution for every problem.McGruff wrote: It's therefore necessary to make a point of debunking the usual OOP canards when they surface and to encourage people to make the step up.
All programmers will, on a long enough timeline, run into OOP. Pushing them headlong into the fray early is the equivalent of saying "Vi" is a great text editor for someone that used WORD.
Telling someone to learn the most complex portions of PHP on a board that is generally populated with less-experienced users is the equivalent of taking a boy that cant swim and telling him to swim the atlantic - "Trust me, when you are done, you'll be able to swim ANYWHERE!".McGruff wrote: Bad advice impedes people's learning process; good advice helps them move forward.
True enough comment.. If you can survive the swim.
And again I say - you can program effectively, robustly, powerfully, and do it without a LICK of OOP - Computer science did so for *decades* without a problem. PHP did it for several years. Its not a requirement, nor is it even a causal relationship - the mere use of OOP does not improve a program. The *proper* use of OOP *can* - just like procedural code.McGruff wrote: This forum is a place to learn how to program well and I'd be selling users short if I didn't do this.
I completely disagree with this, and we've butted heads about it before. OOP is *NOT* written for economy of expression. It is written to be a well-designed expression of what you want.McGruff wrote: Incidentally, a big part of the learning hurdle which new coders sometimes miss is that OOP talks more to the programmer rather than to the machine.
The difference between "Meet me for dinner", and a 10 line sonnet about it.
While the sonnet may be easier for YOU to read, and certainly easier to expand into a novel, it is *not* easier for "most programmers" to read - because most programmers are new, and havent learned OOP.
Further, if POORLY written, that OOP can be a hundred times more complex to understand than procedural code.
Abstraction requires more understanding - its more complex. Of course, much like Sonnets can contain nuances impossible to express in a text message, OOP (if done right) can in fact be extremely elegant and concise.
I can show you OOP code that would curl your toes, and procedural code that someone with no programming experience could immediately understand.McGruff wrote: It doesn't really do anything you couldn't do by other means but it does make code easier to read and maintain.
Like you said: OOP doesnt really do anything you couldn't do by other means! (You should have just stopped there!)
Sonnets instead of text messages! Ahhh the richness, the depth, the.. lack of simplicity.McGruff wrote: With OOP, you can create entities with rich meaning: abstracting archetypal concepts, encapsulating chunks of related code into discrete, swappable modules, or create a common language between programmer and client.
While many of his attacks - plural - are beyond the pale, some of them have a very solid level of accuracy.McGruff wrote: The article/rant we've been talking about may have been intended to deal with databases but in fact goes well beyond this to make a rather ridiculous attack on OOP.
Ah, but in truth - its neither - its Ovaloid. You'd do well not to see the world in black and white, much like the flat-earth-ists.McGruff wrote: The guy is talking out his as* there and I think it's important to say so. OOP programmers will sigh and think "here we go again". Do we make our own blanket statements? Well yes because, to the best of our knowledge, the earth is round, not flat.
OOP (and all PHP code for that matter) depends on the programmer, the problem set, and the goals.
Feel free, and have fun - I have enough experience under my belt that I feel no need to prove myself. You feel that OOP *is* "the most powerful part of PHP". I've experienced that, and also experienced the opposite.McGruff wrote: Perhaps we should set up a coding challenge sometime so that we can compare alternative solutions to some defined problems? At some point, we have to start talking real code.
I'd just really prefer not to hear a non-stop, dead-horse-beating OOP fanclub message in practically every thread.
Thats probably an excellent idea.McGruff wrote: PS: I should apologise to the original poster since it was me who sparked off the OOP "jihaad". I can split this off to a new topic if you'd prefer to get back to discussing your own class designs.