Page 2 of 6

Global $response;

Posted: Mon Sep 12, 2005 6:39 pm
by ttt
I am a self-taught PHP programmer (I use the term loosely as some may be offended by that terminology). I started writing simple form handlers and very basic PHP/mySQL stuff. Then I wrote a shopping cart (3 generations over about a year) that is actually really solid and now I'm writing a customer management application. Though my scripts do what I want them to do, and appear solid, I am always insecure about the fact that I've never had formal training. I worry that a 'real programmer' might look at my code recognizing weaknesses like security holes, performance drains, redundancy, things I can't think of, etc.

It seems to me (let me repeat that), it seems to ME that the code examples that I see containing OOP/classes tend to be written by more experienced/knowledgable programmers. Not to say that OOP people are any more experienced or knowledgable. It just seemed like learning OOP was the 'next step'. I just didn't understand exactly when or how it should be used. I just want to learn as much as I can. I'm not happy with my current level of knowledge given that I pay my bills with PHP programming.

I did not intend to spark any fires with my question. I now see that the act of asking that question was a demonstration of my ignorance. I have read everyones responses along with the links provided, and I feel like I have definately learned something. I now have a greater understanding of OOP, while at the same time feeling more confident about my procedural code (I also now know what the term 'procedural code' means). I feel like each has it's place, and though one style may or may not be superior, I now have a better understanding of how and when/why I will use each. I just want to be confident and proud of my own work.

Thank you all for your responses, I have learned much from them.

Re: Global $response;

Posted: Mon Sep 12, 2005 11:54 pm
by McGruff
ttt wrote:I did not intend to spark any fires with my question.
I wouldn't worry about it. It always seems to happen - please do ask any time you have a question.

If you're doing this for a living I'd strongly recommend that you learn all you can not just about OOP but also about testing. Testing will change your programming life (and almost certainly reveal a few bugs you didn't realise were there).

As well as this place, there's also a great advanced forum on sitepoint.com with many very knowledgable programmers. It's no accident that the discussion there is all about OOP. Look out for a local XP group in your area. They'll probably be talking java but the principles are broadly the same.

Posted: Tue Sep 13, 2005 3:27 am
by patrikG
ttt wrote:I did not intend to spark any fires with my question. I now see that the act of asking that question was a demonstration of my ignorance.
Not at all. Asking questions is no sign of ignorance, on the contrary: it shows that you've reached the boundaries of what you know and want to know more. This very discussion board is dedicated to answering questions.

The differences that came up in this thread have nothing to do with you and go back a long time. As long as you've learned something about OOP, test driven design (TDD) and procedural coding and when to employ any of these methodologies this board has served its purpose.

Btw.: Most PHP developers I know and have known over the years are self-taught. There's no shame in that at all. Some arguments are put forward in a very passionate way about something being the bee's knees - it's a learning curve for everyone involved.

Re: Global $response;

Posted: Tue Sep 13, 2005 7:59 am
by Roja
ttt wrote:I feel like each has it's place, and though one style may or may not be superior, I now have a better understanding of how and when/why I will use each. I just want to be confident and proud of my own work.
I would go so far as to say that OOP is generally superior in the majority of cases.

The important difference that exists between several of the long-timers here that sparks up each time we discuss OOP and procedural code is degree. As you move forward in programming, you will likely run into OOP. Its a somewhat natural progression, as at some point, you'll find a large application that you want to work on, and weeks into it, you'll ask yourself why it is so difficult to maintain.

Questions like "How can I do this better" lead to a meta-programming level of discussion. Suddenly, its not "Which php function is faster", its "Which programming style will get me the results I need". That level of discussion and questioning helps you to step outside the very narrow focus of functions and procedures, and up to the broad strokes of modularity.

OOP is many things: It's a fantastic way to accomplish encapsulation, modularity, and more. It lends itself to more maintainable code, more scalable solutions, and a more robust architecture. Which is why OOP is an inevitable step on the progression of programming knowledge.

However, beyond that distant vista, you will also find yourself understanding yet another level: There is no one best way.

Infolock chalks it up to a matter of opinion, nielsene attributes it to pragmatism, and so forth. The truth is that at some level of programming knowledge, you learn the simple truth that a hammer is not always the effective tool for driving in screws.

But beneath all of those theories, opinions, and ideas, one simple truth shines through: Code is only as good as you make it. If you are completely unaware of OOP, you should be coding procedurally, but looking to learn OOP. If your comfort level is in OOP, thats where you should be programming. But OOP is not the alpha and the omega: There are higher concepts, and further adventures for your mind. Like so many things in life, the finish line isn't defined, and the journey is what you should focus on.

Programmers like Djikstra, Pascal, and Rasmus Lerdorf describe OOP just the way I do: A fantastic tool that you should embrace, and absolutely have in your toolbox, but not the only tool, nor the best tool for every job. These programmers have between them decades of experience programming for the largest possible audience.

As McGruff points out, you will notice that many of the advanced sites discuss OOP, as it is a higher level discussion. However, at sites discussing the meta issues in programming (such as http://lambda-the-ultimate.org/ ), you'll find that the discussions are fairly balanced between OOP, Procedural, and a mix of the two. This is no coincidence either: They've gone beyond the confines of one solution, and are yet again asking: "How can I do this better?"

It seems that everyone posting agrees on two things: You should strive to improve your knowledge, and OOP is a fantastic tool for a wide range of problems. The only thing we disagree on is the degree to which OOP is great.

That alone should show its importance, and that is what you should focus on - it has value in any programmers arsenal.

Posted: Tue Sep 13, 2005 12:07 pm
by infolock
nielsene : if we're talking about obtaining a position, yeah, ur right. If we're talking about the best method in general, no.

all because you say you are using a procedural language does not make it the best. The best method is the method that will in the long run, lessen the overhead/load time. That's all there is to it. If the code looks crappy, well, it looks crappy. But if it does the job better than a pretty procedural-method, sorry, i'm not gonna say the procedural method was "the best method"

Don't get me wrong, I use OOP all the time, but again PHP is not real a real OOP language (yet). It's building more and more along the guidelines set by C++, but it's not exactly there yet.

So, all the issue is is OOP better? In some cases yes. In some cases no. It's all about preference to the programmer, and which method is gonna reduce the amount of overhead (i left that part out in my last message).


Edit : Roja : that is exactly how I see it too.

Posted: Tue Sep 13, 2005 12:36 pm
by josh
I think I can safely summarize this entire thread by saying, the answer depends on what you mean by the word 'better', are class' 'better' for code upgradability, and data relation.. yes, are functions 'better' for simpler things, and in some cases 'better' in terms of page execution time, yes.

Posted: Tue Sep 13, 2005 1:41 pm
by dbevfat
infolock wrote:...
Don't get me wrong, I use OOP all the time, but again PHP is not real a real OOP language (yet). It's building more and more along the guidelines set by C++, but it's not exactly there yet.
...
Just what exactly is php missing that "real OOP languages" have?

Posted: Tue Sep 13, 2005 1:48 pm
by josh
dbevfat wrote:Just what exactly is php missing that "real OOP languages" have?

for one, in php4: visiblity, from my understanding this has been implemented in php5 though

Posted: Tue Sep 13, 2005 3:19 pm
by McGruff
When I was starting out I used to think that OOP looked unecessarily complicated and inefficient. I was simply wrong. It takes a while - a year or two - to begin to grips with OOP and it’s not always easy to find good examples from which to learn. There’s an awful lot of badly-informed comment about it on the net. I really don’t know what people mean when they say php isn’t a real OOP language for example. Trust me, it works just fine, even in php4.

OOP is not inefficient. In any case, programming isn’t about squeezing every last drop of performance out of your code. The days of “64k should be enough memory for everyone” (an old Bill Gates quote) are long gone. OOP can sometimes lead to less code overall or, by its modular nature, allow you to identify problem areas and optimise code more easily (assuming you do actually need to optimise).

The real aim is to create clear, easily readable, easily-maintainable code. “Crappy code” is most definitiely not OK unless you’re a fire and forget programmer. Applications have to be maintained over their lifetime: that’s where most of the work lies. New features may be added, requirements will change. Encapsulation makes that much easier. Testing makes it fly.

It’s not a question of preferences. OOP, particularly OOP combined with testing, is much more powerful. Some simple shell scripts may not be complex enough for classes - although I've got quite a few which are. In a template file, maybe I might have one or two simple presentational functions with php doing the job it was originally designed for. However, everything else is 100% OOP. Email validation for example would certainly be carried out by an object - or rather a whole group of objects designed to carry out input validation. It's simply not true to say that you should only use OOP where "there's a strong relationship between data and processing". There is always a relationship. What people sometimes don't understand is that good classes tend to be lean and focussed on doing just one thing. If that's a simple task, great: you get a nice simple class. If it's not, you get a whole group of co-operating classes each carrying out a specific role.

Nielsene has mentioned that you might have to take a job where the code base is all procedural. Personally, I would never apply for anything where they were not only using OOP but also testing as well. Life's too short and it's just too hard to work like that. There are better ways.

Posted: Tue Sep 13, 2005 4:26 pm
by Roja
McGruff wrote:It’s not a question of preferences.
Several have disagreed with you on that, me among them. But you refute your own comment:
McGruff wrote:Some simple shell scripts may not be complex enough for classes
So it is a matter of degree, and preference. If there are *some* areas where you don't use classes (you've acknowledged there is), then it is simply a matter of degree. Others draw the line differently than you. You put it at slightly above hello world, and shell scripts.

I put it at the level where the relationship between data and processing gets strong.

Neither is wrong, they are simply degrees of the same comment: OOP is great, but there are places where its not ideal.

Deciding where to put the line is a preference, an opinion. An item that cannot be proven, and thus not a truth.
McGruff wrote:Nielsene has mentioned that you might have to take a job where the code base is all procedural. Personally, I would never apply for anything where they were not only using OOP but also testing as well. Life's too short and it's just too hard to work like that. There are better ways.
Unfortunately, that gives a good point to justify a comparison of OOP v. procedural code to academic purity v. reality.

You value OOP above all else. Others are more pragmatic, and would gladly ditch their $5 an hour job at McDonalds for the CHANCE to program procedural, spaghetti code just to get experience in programming.

I think thats a telling statement, which again reveals that it is a preference.

Posted: Tue Sep 13, 2005 4:33 pm
by McGruff
Roja wrote:I put it at the level where the relationship between data and processing gets strong.
I don't know what you mean by that.

Posted: Tue Sep 13, 2005 4:59 pm
by dbevfat
jshpro2 wrote:for one, in php4: visiblity, from my understanding this has been implemented in php5 though
yes, it lacks language constructs for visibility, but that does not stop anyone from making a perfectly working class with privates and all. All it takes is a little self-control and I tell you - it works just fine.

it's not the OOP language, but is a OOP language.

not to mention php5, where you have it all, including interfaces. Maybe there is one thing it needs -- namespaces. But after such a long time without them, ... it's arguable if need them.

Posted: Tue Sep 13, 2005 5:27 pm
by Buddha443556
McGruff wrote:OOP is not inefficient.
Inefficient code isn't the fault of the methodology or language, these are just tools. Inefficient code is always the fault of the programmers.
McGruff wrote:In any case, programming isn’t about squeezing every last drop of performance out of your code. The days of “64k should be enough memory for everyone” (an old Bill Gates quote) are long gone.
That would definitely be one opinion. :? Me I'm stuck accomodating people on shared servers where memory is limited and so is processing.

Posted: Tue Sep 13, 2005 5:35 pm
by Roja
Buddha443556 wrote:
McGruff wrote:In any case, programming isn’t about squeezing every last drop of performance out of your code. The days of “64k should be enough memory for everyone” (an old Bill Gates quote) are long gone.
That would definitely be one opinion. :? Me I'm stuck accomodating people on shared servers where memory is limited and so is processing.
Its an especially odd opinion for a programming language that has a default 8mb limit that is rarely changed on any host I've seen. :)

Posted: Tue Sep 13, 2005 5:40 pm
by McGruff
Are you saying that it is common to run up against the 8mb limit in practice? Of course, as you know, it isn't.

Also, did you mean to suggest that using functions or classes is going to significantly affect this?