Why use classes in web scripting?

[Anon]

I do server-side scripting almost entirely in PHP and Perl. All of my code is procedural. I understand the advantages of creating classes (private namespaces, inheritance, data/method encapsulation, readability, to name a few), but given the statelessness of HTTP, I've never come across a situation where I really needed to create object instances; at most I've needed data structure instances, where arrays and hashes work just fine. Am I way off here? Can someone give me a compelling reason to start scripting in an OO style?

[khaine]

I have never seen a really good reason to use purely oop style php but some classes can be very usefull. I have two classes that I use one does mysql access and the other does oracle access. both save a lot of repeating commands. I think its a case of if you want to use it do but dont kill yourself fitting it into a site.

Mark.

[[deleted]]

A note: http is stateless, but with sessions, your PHP script is not stateless.

A compelling reason? how about:
private namespaces, inheritance, data/method encapsulation, readability, to name a few.

🙂

Those are the strong-points of OO that are 'sorely missing' in procedural programming.

For ex: in my forum I need to query the database for authentication and for content.
So I created a database access class, and extended the authentication and content classes on that. That means all authentication and content objects automatically have their own database access functions, and all the data retreived by those functions stays inside the objects.
I can query for authentication and for content without having to worry about overwriting resultsets etc.

Added bonus: registering the objects in a session automatically registers all it's content.

Little-known but very cool bonus: classes can have a sleep and wakeup method which are automatically executed at session-save and session-start. That means you can put the database connect and disconnect in there, and have your objects disconnect and re-connect to the database automatically. schweeeet.

In the end, there is really nothing you can do with objects that you cannot do with functions. BUT! Doing the same with functions means a lot more work for you as a programmer.

for ex: I need authentication functions to verify what my users can do.
But if I want to edit a user's rights, I also need to do what that other user can do.
Now I can create extra functions to allow the class to work with more users, or I can create a second copy of the authentication object. The second option saves me a few hours work. :-)

[shmert]

Probably the most useful class I've written is a hitlist class. Example usage:
<ff>
list = new Hitlist("SELECT name AS Person_Name, email AS mail FROM user WHERE x=y);
list->setAltColor(TRUE);
list->setMaxRecords(50);
list->setColumnFormat(2, "mailto");
list->printit();
</ff>

This will print a nice hitlist with alternating row colors, sorting buttons on the header, the second row hyperlinked as a 'mailto', next|prev pager buttons, etc.

The nice thing about having it in a class instead of a function is, it's much more modular. You can have two different hitlist classes on the same page. You can pass as many parameters as you want, using methods instead of having one procedural function with a huge parameter list that nobody will ever remember. Since many people are using this class, I can make internal changes or add accessor methods as long as I keep the existing API the same.

One the downside of PHP OOP, I've run into problems storing my objects in sessions. You have to jump through some strange hoops, such as serializing your object, then unserializing it AFTER session_start, etc. etc.., and it ends up flaking out. Also, passing objects to other objects is a recipe for frustration, because the target object cannot make any changes to the initial one. I gave up my attempts, and am now moving to WebObjects for my serious OOP development, which is SO nice after struggling with PHP's lackluster Object Oriented support. Because PHP is at heart a procedural language.

[Anon]

Sam Barnum wrote:

One the downside of PHP OOP, I've run into problems storing my objects in sessionsYou have to jump through some strange hoops, such as serializing your object, then unserializing it AFTER session_start, etc. etc..

Umm.. sessions in php4 automatically serialize

An excerpt from this page:

http://www.php.net/manual/en/language.oop.serialization.php

If you are using sessions and use session_register() to register objects, these objects are serialized automatically at the end of each PHP page, and are unserialized automatically on each of the following pages. This basically means that these objects can show up on any of your pages once they become part of your session.

[requiem]

To save time and keep things logical without getting stuck in a spaghetti of code and functions which you can't remember why they exist.

Perhaps if you are writing a small site then it isn't so important, or maybe you just use PHP in your free time or as a small part of your day job. But I use it day after day and couldn't live without classes and the many hours they save me. No messing around with arrays and passing them between multiple function calls, instead I can ask my script to $user->update($id,$info) and I know that my update function can access other details about my object without the need for copious "global" statements or worrying about over-writing variables you shouldn't do.

Most people don't really appreciate the power of classes until they find they can't live without them. It's not because they are faster or provide more features than normal functions, it's just because they are logical and a god-send to a programmer going back to code a few months later 🙂

Cheers,

Rich

[zachdyerdesign]

I was doing functional programming and I didnt like the way my code looked. Yeah sure it worked but it was ugly as all get out. So I put my database code inside a database class and that alone cleaned it up pretty nice. Then I extended the class to a meta class to clean up my meta data like my title and description I had tucked away in a database. It made my code look a lot better and as a result peace of mind. So to answer the question why use OOP. For peace of mind and piece of program.

[antmeeks]

My two cents...

Classes are very useful for creating reusable components in an "application" (like database ops, file system ops, etc.)

However, the movement towards OOP programming in PHP is basically just a solution in search of a problem.

PHP is inherently procedural, and you can't really create "applications" in the proper sense... No matter how hard you try, whatever you create in PHP is just a script.

PHP will always process from one line to the next, on and on, until your script is complete or terminates in an error.

All of these OOP embellishments, and the frameworks they've spawned, while occasionally useful mostly only serve to overcomplicate something that, at it's core, is and should remain very straightforward and simple.

Even Rasmus Lerdorf, php's original creator, believes that OOP frameworks lead developers down the wrong path with php in that you're not developing for the specific task at hand. Add to that the fact that when you utilize a big, verbose OOP framework, you're adding a ton of unnecessary overhead to your code.

Again, a reusable-component approach to php is very valid and smart, but before you start going down the rabbit-hole with OOP-ifying your script, ask yourself whether you're making something more complicated than the task really requires.

JMHO.

[zachdyerdesign]

antmeeks;11006144 wrote:

PHP is inherently procedural, and you can't really create "applications" in the proper sense... No matter how hard you try, whatever you create in PHP is just a script.

PHP will always process from one line to the next, on and on, until your script is complete or terminates in an error.

Most languages I've worked with such as php, javascript, and ruby seem to process the code from top to bottom. I assumed all languages were like that. Is this not true?

[antmeeks]

zachdyerdesign;11006145 wrote:

Most languages I've worked with such as php, javascript, and ruby seem to process the code from top to bottom. I assumed all languages were like that. Is this not true?

No, not all languages are like that.

It's important to remember that PHP and the others you listed are not actual programming languages. They're procedural scripting frameworks, really.

The most obvious difference between the two types being that you can't spawn off separate processes that run concurrently with the main script

[zachdyerdesign]

antmeeks;11006147 wrote:

The most obvious difference between the two types being that you can't spawn off separate processes that run concurrently with the main script

😕
I'm new to programming so can you give an example of what your talking about?

[antmeeks]

I'm new to programming so can you give an example of what your talking about?[/QUOTE]

Scripting languages allow you to send commands directly to a script interpreter that executes these commands, line-by-line. e.g. Python, Javascript, PHP, Ruby, etc.

Programming languages allow you to create a multithreaded program that is compiled all at once at runtime by the system and converted into unreadable machine code to be executed by the system. e.g. Java, C/C++, Obj C, Visual Basic.

[NogDog]

antmeeks;11006151 wrote:

Scripting languages allow you to send commands directly to a script interpreter that executes these commands, line-by-line. e.g. Python, Javascript, PHP, Ruby, etc.

Programming languages allow you to create a multithreaded program that is compiled all at once at runtime by the system and converted into unreadable machine code to be executed by the system. e.g. Java, C/C++, Obj C, Visual Basic.

No, PHP does not get processed line by line. It gets compiled at run-time, and in every other (basic) regard is just like any other programming language that is compiled into a separate executable (or byte code) file. It is most definitely NOT like some old interpreted languages that were, in fact, read and processed one line at a time.

PS: Way to resurrect a 10-year-old thread. 😉

[zachdyerdesign]

NogDog;11006153 wrote:

No, PHP does not get processed line by line. It gets compiled at run-time, and in every other (basic) regard is just like any other programming language that is compiled into a separate executable (or byte code) file. It is most definitely NOT like some old interpreted languages that were, in fact, read and processed one line at a time.

PS: Way to resurrect a 10-year-old thread. 😉

Please explain what older languages your referring to.

[antmeeks]

NogDog;11006153 wrote:

No, PHP does not get processed line by line. It gets compiled at run-time, and in every other (basic) regard is just like any other programming language that is compiled into a separate executable (or byte code) file. It is most definitely NOT like some old interpreted languages that were, in fact, read and processed one line at a time.

PS: Way to resurrect a 10-year-old thread. 😉

Hey, don't get mad at me, I didn't resurrect it, zachdyerdesign did! 😉

The PHP script interpreter is written in C++, and while the interpreter gets compiled at run time as it's own executable, whatever you've written with the PHP code itself does not.

And I'm pretty sure that PHP scripts do get read and processed one line at a time by the interpreter, which is why one error on one line can fatally terminate the script.

[zachdyerdesign]

antmeeks;11006156 wrote:

And I'm pretty sure that PHP scripts do get read and processed one line at a time by the interpreter, which is why one error on one line can fatally terminate the script.

Sometimes I get a list of errors in chronological order. For example I get an error because I have an invalid mysql connection and it will also say I have a invalid mysql fetch array on the next line. Is that any different than javascript?

[NogDog]

antmeeks;11006156 wrote:

Hey, don't get mad at me, I didn't resurrect it, zachdyerdesign did! 😉

The PHP script interpreter is written in C++, and while the interpreter gets compiled at run time as it's own executable, whatever you've written with the PHP code itself does not.

And I'm pretty sure that PHP scripts do get read and processed one line at a time by the interpreter, which is why one error on one line can fatally terminate the script.

They get processed one compiled command at a time -- which is not necessarily the order they are in the source code -- since PHP is not multi-threaded, but that is not the same thing as, say, the original BASIC language, where one source line was read, interpreted, and processed at a time (which is why the source code had to include line numbers in case you ever wanted to do any branching logic via a GOTO command).

In other words, your entire* PHP source code gets read in and compiled, and then that resulting compilation is executed (in whatever sequence the compiler ended up organizing things in the resulting executable bytes). That's why if you have a parse error in line 100 of your script, nothing gets executed even though there may have been 99 commands in the script before that parse error.

---

• It may deviate a bit here from non-run-time compiled languages in that conditionally included files may get parsed/compiled during the actual execution of the main script.

[zachdyerdesign]

NogDog;11006158 wrote:

In other words, your entire* PHP source code gets read in and compiled, and then that resulting compilation is executed (in whatever sequence the compiler ended up organizing things in the resulting executable bytes). That's why if you have a parse error in line 100 of your script, nothing gets executed even though there may have been 99 commands in the script before that parse error.

I have never tried this but if what your saying is true that would mean I would not get an error if I included my class after I used it. Is that correct?

[antmeeks]

NogDog;11006158 wrote:

They get processed one compiled command at a time -- which is not necessarily the order they are in the source code -- since PHP is not multi-threaded, but that is not the same thing as, say, the original BASIC language, where one source line was read, interpreted, and processed at a time (which is why the source code had to include line numbers in case you ever wanted to do any branching logic via a GOTO command).

In other words, your entire* PHP source code gets read in and compiled, and then that resulting compilation is executed (in whatever sequence the compiler ended up organizing things in the resulting executable bytes). That's why if you have a parse error in line 100 of your script, nothing gets executed even though there may have been 99 commands in the script before that parse error.

---

• It may deviate a bit here from non-run-time compiled languages in that conditionally included files may get parsed/compiled during the actual execution of the main script.

I wasn't trying to compare PHP to something antique like Basic...

I was only trying to clarify the distinction between the limitations of the PHP scripting language vs. the more advanced features of a full-fledged programing language.

[laserlight]

antmeeks wrote:

It's important to remember that PHP and the others you listed are not actual programming languages. They're procedural scripting frameworks, really.

antmeeks wrote:

Scripting languages allow you to send commands directly to a script interpreter that executes these commands, line-by-line. e.g. Python, Javascript, PHP, Ruby, etc.

Programming languages allow you to create a multithreaded program that is compiled all at once at runtime by the system and converted into unreadable machine code to be executed by the system. e.g. Java, C/C++, Obj C, Visual Basic.

This is yet another false dichotomy 😉

For example, using the Zend optimiser, PHP code can be compiled into bytecode. Likewise, Python code is typically compiled into bytecode. Java code is also typically compiled into bytecode and executed by a virtual machine. C++ code can be run by a runtime interpreter.

We tend to assign the designation of "scripting languages" to languages that were intended for use as such and/or typically used as such, but often these "scripting languages" really are programming languages. They are Turing complete and can be general purpose as need be.