ok i've found myself at the point of

learn

 ing  to program that i've come across OOP especially in

php

  but i wanted to keep this discussion more general than any specific language. you see the thing is i don't get the advantages of using OOP. functions yes, that little step in the curve really got my

programming

  organised and tidier. obect oriented, no. it just feels like i'm

learn

 ing  to program from scratch again. new syntax for both making classes and instantiating variables,etc,etc..
so whats the point of

learn

 ing  to program this way. i mean i can read, use and edit other people's classes/objects if i need to but i don't see more of an advantage to say using include files and functions.
why do you program object oriented?

LOL, I hear yah.  I really don't like OOP in

perl

 .  It's flaky and the modules are not well explained anywhere on earth.

I use

perl

  OOP cuz I have to, heh.  The only

perl

  oop I use, (almost), is LWP which is the web client "simulator".
My alternative would be to get into low level socket

programming

 .

I have a real hard time understanding the terms "classes", "objects", and "methods".  I have read the
explanations many times.

In

perl

 , there are modules that make big promises, but do little or nothing but waste my time, mechanize come to mind.

OOP evolved from more basic techniques and now it's the "in" thing. 

Of course, if you are familar with a

perl

  module or

php

  class, using it can save a huge amount of time.

Many

perl

  experts have told me "use the modules, don't reinvent the wheel".  bullshit!

There are those that are content to just drive a car and there are those that need to take the engine
apart and reassemble it.

dig?

in other words, i dunno,
Bompa

OHHHHHHH BL

ASP

 HEMY

Im an OOP nut, oop simply rocks when used pro

perl

 y.  The reason it works so well is because it models not only the way your brain stores information [loosely of course] but also real life.

I must point out that i never use OOP in

php

 .  Namely because im a slack

php

  coder but in C++ and other langauge oop is the only way.

Say for example you are creating a project to display a number of objects on the screen [i will use c++ as reference]
So you know you want X number of objects.  All of them will need X and Y coordinates, and maybe a vector to describe any movement they may have.  If we dont look at the display side of thigns we can see straight away that each of our display component has at least 3 things in common.

So we put them into a class, say VisibleObject which encapsulates those methods and variables.  Meaning we KNOW that if an object is a visibleobject it will have coordinates etc.

So not onyl have you saved yourself a few hours work worrying about

typo

 s you also can check if an object is a visible object.

For example you may have a list of objects, some visible, some other objects, helper objects or something.
How can you tell which ones should be displayed and which ones should not be?
Easy you can cast each object in your list to a visibleobject type, if they are a visible object you will get the visible object portions of the object, else you get nothing.

I know this may be hard to understand, and what ive mentioned is very limited in its use of OOP, but my aim was to try inspire you to look further into OOP and how it can be used to reinforce your coding integrity AND save you time

I'm with monkey on this and I'll offer another perspective (this is why you use LWP Bomps);

Say I have a browser object (class), I can put this code in ANY program that needs to grab a URL;

$myBrowser =& new Browser();

$response = $myBrowser->get( $target_url );

And I know $response is going to contain the target page every time. It has already been debugged, tested, used many times. IOW I am leveraging not just someone elses code in a simple package but all the dev, debugging, testing. Yes, the same advantages could be acheived with procedural code, function library perhaps, but it would not be as easy to use or distribute. You'll see that a lot of the stuff posted is in classes, I don't think I would be as likely to use one of perk's peices of code if they were an aggregation of functions rather than a class.

Of course there are other advantages, some of which monkey has touched upon, some which have not been touched upon such as code obfuscation and "data hiding" the concept of private parts of an object which are for internal use only.... etc.




Cheers,
td

i actually am going to side with the OOP is a Meh side, most of the time.

I do alot of code repair and system retooling, and i gotta tell you, people use OOP way too much, for no reason, and make things way more complicated than it needs to be.

for example, in

asp

 , the common way to create a connection to a database in ADO is this chunk:


thats it. 2 lines. yet... I see people wrap that in a stupid class, so often its become a joke to me. it makes the code less readable, to save 1 line of code. it also causes 1 extra parse level (create and object, which again creates and object).

now....

where this does make sense is when you have a "thing" that you need to work with repeatedly, over time, and might have different statuses, modes, values, etc, every step of the way. to use a car as an example. the cruisecontrol function.
cruise = new cruisecontrol
cruise.set = 50
cruise.currentspeed = speedometer.speed
cruise.adjustspeed

these are all related controls of the single concept of cruisecontrol. so it makes sense.

but i find more often than not, that OOP gets in my way when doing the coding I do, both my own web development and my code repair work. however, this could just be a side effect of the type of work I do. web stuff tends to be 1-off functions most of the time. and repair stuff is web as well.

but if I was writing a game for example, OOP would be my jesus probably.

Good point, using OOP for the sake of OOP just defeats the point.

I think possibly the best use of OOP in

php

  that is easily accessible to those

learn

 ing  is

php

  mailer of freak

php

 mail
i forget but its on

php

 freaks or something

They extend the main

php

 mail class beautifully and simply to save you constantly re-entering info
Definately worth a read, sorry youll have to google it i cant remember its exact name

This is going to be a great discussion. The question, is why OO

programming

  is superior to virtually every other methodology in practice today.

First off, let's get entirely away from

programming

  for a moment and talk about an office environment. In a normal office, you have a variety of workers that perform tasks. We use EMails, IM, meetings and most specifically English to interact and discuss what we need from each other to accomplish the overall goal. I think it's fair to say, that most often, the sales department is equally important to the engineering department, but neither really understands the ways that the other work. Let me be more precise: if the salesmen have been using "Act" for their customer contact information and choose to change to "Goldmine," should this even remotely affect the engineers? If the engineers stop using a straight-line perspective mechanism for their designs and go to a 30 degree flat perspective, should this affect the salesmen? Moreover: if a salesperson is underperforming, and the management decides either to grow the staff or replace the unproductive element, should that affect engineering? Even more specifically: should the engineering department have *any say whatsoever* in how the sales team should be doing their job?

In OO methodology, we use the term "encapsulation" to ... ah ... encapsulate this thinking. The notion is that a "thing" knows how to do it's job, it has the tools do do it's job, the mechanics of how it does its job is hidden from anyone else and noone else can get in and mess with how the job is done. This is a VITAL component of OO thinking because of the size and complexity of systems. My second retail framework (still online today and doing fine) is over 200K lines - spanning from marketing to operations, inventory management, email blasting, robust, capable and quick web sites, back office management consoles and telemetry... if that was one huge monolithic program I'd just be RATFishED if I changed a variable name - who knows what else I might be screwing up? For the same reason that physicians cannot entirely predict the affect of a new compound in the human body (take pill for headache, toe hurts...?) the Windows team has a monumentally difficult task understanding how the input of a new variable affects the entire system. So, using encapsulation we can know that an object's job is wrapped up tight and unfishwithable by any other object.

Encapsulation also offers a magnificent

programming

  advantage for folks like me that have to handle lots and lots of code. When I can "wear the hat" of a particular object's perspective knowing 100% that my only responsibility is to <that> object's functionality and it's relationship to the world, I can quickly and easily get my arms around "the entire scope" because the entire scope is so much smaller than the entire application. In that way, I can create systems that are vastly more complicated than I've ever even dared to dream.

Back to our office for a moment, let's talk about the legal team. When we started our business we only needed some general legal counsel, so we got basic lawyers. But as engineering started to created more creative things, it became apparent that we needed more specific strengths, so several lawyers went to school and added patent law to their educations. Later, because of the nature of our business they also needed to get additional strengths in certain elements of technology and technical patent law. We were able to grow the capabilities of our lawyers without losing any of the previous skills they had - the took what they new about law, and were able to add to it.

In OO this is called inheritance. The stucture of a class hierarichy is such that you can build upon code that you've already written without having to redo it, and yet take full advantage of what you've already built. Here is an example of a class hierarichy I have for a request/response mechanism I use. This class structure allowed me to write code that interacts with credit card processing, other folks web APIs and a variety of travel vendors with extremely little modification. And when I discovered that I fundamentally missed a critical piece, I was able to add it to the root class and all decendent classes instantly were able to take advantage of the upgrade. Here is the breakdown:

requestorBase
structuredRequest
socketRequest
secureSocketRequest
merchantProcessingRequest
linkpointRequest
httpRequest
httpsRequest
travelBaseRequest
[vendor]Request
[vendor]Request

In this structure, Ive placed the most essential elements of a request/response interaction into the requestorBase. This includes function declarations for dispatch and receive, variables to hang on to the last sent and last received valus and other maintenance items. The structured request adds to that the notion of request and response parameters, as well as events for handling/validating each. Note here that this class does not *implement* them, it describes their existence and interaction side of all decendent classes. The socket class and http class (on the same level) add the functionality of understanding talking in either a straight socket way or in an HTTP way. of course the child classes in each of those separate lines add a secure layer to them. Finally in this tree we can see some real specificity occuring: a merchant processing base adds the notion of secure keys, amounts and some validation points I need to talk to merchant processing gateways - I've called out one of them, "linkpoint" which is my gateway when I transact over Card Service International - while the travel base adds some specifics for talking to travel content providers (SABRE, WorldSpan, various wholesale tour outlet databases) and finally the base request for each vendor, because each travel vendor has a specific type of details and idiosyncracies that I need to deal with.

So: I need to add logging to my requests because I want to see the entire log of interactions: I added it at the requestorBase level. Kerpow, it's available to every class in the tree instantly. I wanted to add a particular type of date parameter to my requests - it goes in the structure level. You see what I am getting at here - additions and upgrades appropriately placed along the tree makes it so that all classes decendent get the benefit.

The last real tenent of OO thinking is polymorphism - which frankly is considerably more important in structured and early-bound languages like C++ and ObjectPascal than it is in modern scripted languages like

PHP

 , becase

PHP

  doesn't give a shit about what you ass (or eve IF you pass) params in the first place. The notion of polymorphism is that you can pass any type of value into a function and the function will accurately identify the type and do the appropriate thing with it. The most common example is the "StringValue" function - where you pass any form of primitave or object into a function and it will return the string value for that... be it another string, numeric, boolean, array... doesn't matter. Well today at least in

PHP

  the polymorphic capability of a function is again, right in the fact that

PHP

  doesn't care what you pass it - so you need to trap the type in code rather than at the object interface level.

OK my dissertation was way long winded, but important: the majority of people I speak with think that OO is a different syntax. Couldn't be farther from the truth: in fact, OO is a way of thinking that they needed to work *really hard* to get it back to a syntax that was understood by programmers. OO is a way of mapping the natural interaction of people and things in the world to

programming

  languages. It is easier for me to envision a monumentally complex system if I can perceive it through the lens of "It looks just like a company" and then deal with the individual capabilities necessary for each member of my company to have, so that I can profit and prosper.

OO gets a bad name because of shit programmers, not because of what it is. Does it add bloat? No. Shit

programming

  can make straight up functional

programming

  bloated as hell. Does it sometimes mean more typing? YEs. Does it mean more thought up front? Hell yes - that's one of the things that makes it great. And n00bs take heart - there is an old truism about OO

programming

  while you are

learn

 ing  the ropes: the 3rd time you build it is when you get it right. A bummer to be sure, but changing how you think to take advantage of this is both a bit time consuming and HUGELY worth it on the other side.

Trust me on that one... 

/p

What an explanation lol
Very well explained lol
Much better than my lame attempts lol

If your entire project is over 250-500 lines of code, OOP is the way to go. Otherwise, I would say stick to just using functions. I agree with perk that OOP gives you a TON of good things, but you're never going to have the opportunity to use those things if your project is tiny.

The first language I really "got" was Java so I think in OO terms, but I haven't done any OO

PHP

  code (even though there are a few projects where I really should have).

Agree CDC unless that project can be 50-100 lines because you make clever use of your existing class libs. This is why I spend a lot of time on my so that my actual applications are really tiny.

/p

great discussion and confirms what i was thinking with my current small scale

programming

  base i think i'll just stick with my function library until things get to a stage when oop will really be a big benefit rather than converting it all now.
as for your comments about keeping it small with oop (@perk) thats kinda why i made the function library in the first place.simple function calls such as:
$urls = grabGoogleSerps($query,1000);
$result = doSomething($urls);
is keeping it small for me!!!! (but i know what you saying  )



lol thats what took me down this path in the first place but i'll get to pseudo threads in another thread!

OOP is a catchy term that means little
I am still sick so i can not comment pro

perl

 y.
but encapsulation, inheritance etc,you are lead to believe that these only exist if u use classes etc.

function area("square",x,y)
function area("circle",r)
function area("triangle",b,h)

the advantage of a functional based system over OO is there are no side effects, sideeffects cause nasty bugs which are hard to detect, if not impossible.
you can see how a squares area is computed.
you get polymorphism still (depending on the language)
the string ("circle" etc) depending on the language would be a constant or enum

OO has its place, but for the most part is way too over used.

here's an opportunity to begin a transition to OO in a gradual way and protect yourself from namespace collision by employing another OO concept, the concept of the namespace.

Say you wanted to create a namespace called "itchylib", you can do this with a "container class" essentially creating a namespace thusly.
If you were to take a file of all your functions and put the following at the top;

class itchylib
{

and;

}

at the bottom of the file to close the container class you would then call your functions using the following syntax;

$urls = itchylib::grabGoogleSerps($query,1000);
$result = itchylib::doSomething($urls);

Or depending on the implementation you could create an instance of (instantiate) the class;

$thelib =& new itchylib();
$urls = $thelib->grabGoogleSerps($query,1000);
$result = $thelib->doSomething($urls);

There you go dude you've already created a useful class without even knowing it 

As mentioned above, you get the added benefit that if you include a file with a doSomething() function in it you are protected against a name clash.

So, there you go, three lines of code in your function library file and your into OO 

Cheers,
td

Oh, BTW, this is the other thing OO excels at, wrapping up and distributing class libraries, vast amounts of code with plug and play interfaces.

In C++ take a look at boost, libcommoncpp2, libwww (intentionally not mentioning the MS stuff coz that would just be too obvious).

In

PHP

  take a look at

PEAR

 , I love

PEAR

  

Cheers,
td

Gobject system, which glib and gtk based on,
http://en.wikipedia.org/wiki/GObject

if u have time to waste check it out to see how OO is made with C,
Also has signals too .

Very cool nop, rock on!

Cheers,
td

sorry to hear that, i just got over a bad sinus/head cold thing last week


get better soon nopster

Ditto Bomps - get well quickly nopinstein.



Completely disagree.

Now: Is it possible to completely misuse/overuse OO? Get lots of great stuff done without it? Absolutely. I was a structured programmer all through the 80s and I still do a tremendous amount of working in that way.

But OO is a way of thinking that goes beyond the language, and that's my point. My entire system is designed from an OO perspective - even my hardware layout and choice of language tools... it's how you perceive the architecture and build interrelations between entities - in fact, true OO thinking is way UNDERUSED in my opinion - people use the syntax of an OO language without using the real ideas and methodologies that make OO what it is.

Get well soon!
/p

Make sure u wash ur hands before u eat, and do not catch infectous diareha , on the bright side at least it was not typhoid.
and you need another one with it coming out the other end
If any of u are traveling in tropical climes and you catch something like that, the proceed to nearest hospital since dehydration is a big danger

Everything perks has said about OO is true. Probably 3 years ago I would have agreed with him 100%,
I was even one of those anoying people who boast about

python

 's fantastic OO abilities and how other languages suck .
Any problem can be solved providing you can divide it into 2 parts, data and the methods that act on the data.

Just to note, i am not big on terminology. i use term classes/objects interchangably.
theoretically class should be like the specs, and object should be the instance of the class.

For something like a store it works fantastic.
you make a basic store object (it is not designed to be used directly), then you make various subclasses off it.
you can even make methods so that the object can be serialized into a database etc.
(For the above in

python

  sqlobject rocks, you can even change databases, without changing code).

Anyway as part of a large project that ended in diaster .
I attempted to implement the matroska format in

python

 . http://www.matroska.org/
It is a audio/video container format. It is basically like a set of matroska dolls.
I attacked the problem in the classical OO strat.
Create a basic class. Then inherit new classes from the old one.
OO in this case blows up.
You end up with a million classes (exageration), also as new codecs are added new classes have to be added.

To add complexity to it. As you parse the matroska file, what you read prior will dictate what class you will create in the future.
(possibly this class might not even be implemented yet, you have to be able to handle that).

To try and solve this problem i

learn

 ed about meta-classes, classes that generate classes.
Metaclasses are very hard to debug, and mind boggling.
(The are kinda like

mac

 ros, except you are making classes).

I then attempted to make my own parser that would read in the matroska file format specs.
(basically something like this http://www.matroska.org/technical/specs/tagging/index.html except that in file format i could parse etc)
from this it would create a parent class of an element, which i could subclass to customize it.
You end up with massive ammounts of code. Classes all over the fuking place etc.

All of the above solutions could have worked.
But they would have required an army of programmers.
As perks said in an earlier post way back, OO actually makes your code bigger.
That in itself describes the biggest problem with OO.

Anyway i walked away from the above project. Partially because of the failure, also because of continously changing requirements.
Somehow

python

  and OO had failed me, not quite sure how, but .... .
Kinda like you have been sucker punched, but you are not from sure from where or how .

Any I started to look at other mainstream languages.
Basically all the same soup.

Python

  and

PHP

  except for the libraries and syntax are basically the same language, no really new ideas.
C#,java,C++,object pascal (delphi), same shit different pile.
You start into pissing fights about who has a bigger library.

I then saw articles like http://en.wikipedia.org/wiki/ICFP_

Programming

 _Contest
If these mainstream languages are so hot why are the greatest minds using languages like ocaml, haskel,

erlang

 , dylan etc.
I heard about this stupid language called lisp. Useless fuking language, all fuking brackets.

Anyway i started to look at ocaml.haskel etc.
I could see there was something there, but too much theory not enuff doing .

Anyway as i was pondering how I can earn a living in a country where i have no education, unable to speak native language etc,
no job, lots of free time 
On a board some posted free

programming

  lectures from MIT. (or some shit like that).
Anyway contained in the link was this gem.
http://mitpress.mit.edu/sicp/full-text/book/book.html

What differs that book from 99.9% of the books out there is that it shows you how to think.
It is an amazing book it starts from the most basic principles, to how to make a huffman encoder in like 100 lines of code,
to even making your own compiler. Real practical shit. Not one of these retard books, here is how you use the API to fetch a webpage.
Ways to solve problems.
Most intresting the book used scheme as the language.
With lots of idle time on my hands i started to work thru the problems in the book.
3/4 of the way thru the book i ran into the syndk8 board.
Just for kiks i started to build my programs using chicken scheme.
I found out that once i was over the

learn

 ing  curve, my programs where more robust, easier to debug etc.

Along the way the OO strawman was kiked down.
Because of the

mac

 ro ability in scheme it has multitude of OO implementations.
http://chicken.wiki.br/Eggs%20Unlimited#Object-oriented%20

programming

 
(I am not promoting scheme/lisp but also showing that what OO is kinda vague).

OO has its place.
But the big reason why OO is so popular is that it is very attractive to higher ups and managers.
Here is a way for them to feel as if they are in control of large projects with lots of pretty inheritance diagrams.

Yes i still use

python

  quite often.
Yes i use OO quite often.
Don't throw out the baby with bath water.
No i am not trying to convert people to using some wierd language with brackets.
Go get ur own experiences
But know the limitations of ur tools.

That was great nop - sounds like having the shitz has not addled your brain.

Of course, you are 100% correct - the wrong tool for the job is just horribly wrong. It's like using SGML to design a site scraper. And I am often bombastic in my love of OO thinking - this is probably because so goddam many programmers I work/have worked with just don't think at all... and PRECIOUS few think the way you do. (That was a compliment, BTW).

Your example is well stated and appropriate.

but I'm still an OO fanatic



Finish getting well and come talk more about other languages I don't know shit about my friend

/p

actually nop makes more sense now that he finally took a good shit.

nutballs:

What you are seeing is the moving of the data access pieces to seperate classes for the sake of seperating the layers of the application.  Thusly, the business logic layer classes that access these data access layer classes can be coded so that they do not need to be modified if the database used by the data access layer classes change (say Oracle to SQL Server or such).  Such packaging and division could be done in procedural

programming

  albeit a bit messier.

Where things get (almost) silly is web development where it is really easy to have two or all three layers of the application in one class (i.e. the page class in

.NET

 .  It makes sense to do so for many smaller pages...the kinds of pages many of our web sites turn out to be but what if you were making more of a web-enabled application for HR, accounting, graphics, etc.  Then you would definately be seperating things out a bit more.

Web

programming

  took OOP a step back but as web

programming

  gets more intense, it is returning to its normal course.

not really directed at nutballs:

The benefits of OOP truly are the common cited benefits of OOP:  encapsulation (i.e. data hiding and autonimity), inheritance, and polymorphism.  It does allow us programmers to model things more like they are in the real world.  About the closest you get to OOP in a non-OOP environment is structs/structures each within their own module or include file.

The first, encapsulation, is basically what monkey and td touched on above (an "arachnid" base class has all the properties [i.e. 8 legs, etc.] and methods/functions [i.e. eat, walk, etc] of arachnids).  The second, inheritance, allows re-use of existing code that you then add to (say an "arachnid" base class is inherited by the derived classes "spiders" and "scorpion" - each adding their sub-arachnid specific properties and methods..."web weaving", "tail with stinger", etc. to the appropriate derived class).  Finally, the third, polymorphism, tied to inheritance to some degree (and somewhat alluded to by monkey) allows us to rattle through a list of objects invoking the commonalities of base classes and derived classes.  It also allows the tweaking of those base class methods/functions to be customized for the derived object as well as have various versions of the same method/function (overloading) by way of varying parameter lists.  If we grab an object (an actual instantiation of a class), being it the "spider" or "scorpion" or even the base "arachnid", we can execute the common methods or diddle the common properties of the object no matter what type (class) it is.  This last feature makes more sense when you think of a group of graphics objects instantiated from a "pixel" base class and any number of derived classes such as "line", "triangle", "square", "circle", etc.  Each of the classes has a "draw" method/function.  So you iterate over the screen/view/canvas object list invoking the "draw" method/function of each object found in the screen/view/canvas and each object, regardless of the class type it is (i.e. pixel, line, square, etc.) gets drawn on the screen without you having to check for what type of object it is.  This is where the old linked lists, collections, or arrays of objects come in handy.

I started out

programming

  before OOP platforms were readily available to the masses so I grew up "procedurally".  This really threw me for a loop for a bit.  I have always stated that those entering

programming

  now, with an immediate emphasis on OOP, will have an easier time with OOP than those converting from the old methods...at least in terms of what OOP offers and not necessarily in terms of what

programming

  generally encompasses.

SB

Edit:  Handful of

typo

 s.

Guess I should have read the entire thread before my long reply above!    Oh well.

SB

Nice add anyway SB... nice to see we're all on the same page autonomously... 

You know, I've literally only just started

programming

 

PHP

  OOP
I always used to program it procedurally as I never really saw the point in it.

I always thought
1) It doesn't have enough power to do any funky OOP stuff
2) My web apps aren't generally that complicated to warrant the extra work
3) I have no idea how performance is affected by classes in

PHP

 

A few weeks ago I started to re-write on of my staple sites, been around years, its my baby, I love it
Started to look into OOP

PHP

  and although it still sucks its sooo much nicer to work with, and have even found myself wanting inheritance and class specialization models which i NEVER thought I would do!

I still have no idea about performance but it generally doesn't go any slower.
One thing that does worry me slightly is this.
When

apache

  creates a process to handle

php

  connections it keeps it alive and re-uses it a lot.
If a

php

  script grows in memory requirements the process memory will increase also, reducing the amount of memory for other processes.

So if you have one big script that sucks up a lot of memory [im thinking a class here] then that process may stay active for hours handling other requests that might be a simple query, but its still taking up loads of memory.

Do any of you guys have thoughts on this? Is it a non issue or is it a case of close your eyes and hope?

I thought

apache

  had an equivalent of garbage collection to stop this being an issue, can't for the life of me remember where I read about it. "

Apache

  memory allocation" rings a bell I think...... lol, dunno and don't have time.....

Cheers,
td

I hit that wall alot too.  My current project is big and I think warrants OOP.  However, I am predominantly using the objects on the "creation" (and altering) side and less on the "display" side.  By that, I mean, when users are creating (or altering) a new widget on/through the site, I use objects with all the bells and whistles they offer and seperate the DB access with its own object layer.  On the "display" side, since display usually involves displaying a bunch of data from a bunch of possible 'loads' of the object, it is simpler and faster to just dump to some display structure rather than load them up into an array of objects or such.  I do leave stubs in the class for the display methods/properties bet leave a little comment referencing the web page that usurps that functionality.  For a desktop app, it makes more sense to go OOP all around.  With the continual reloading of data for web pages, it makes less sense (unless you want to pass hidden fields or serialized objects in sessions or such but sometimes you want to pass alot).  Throw

AJAX

  into the mix and you open yourself up to more tweaking possibilities.

SB

Edit:  Sometimes it makes sense to use the objects on the "display" side of web apps.  Of course, the "display" side of the web app, even if dedicated objects are not used for the widgets within, can be wrapped in a class too (like all web pages are classes that derive from the "Page" class in

ASP

 

.NET

 .

Although there is a little more code to OO projects, the overhead is actually pretty slight. Here's the deal: once the code is compiled, you don't pay for it to be included in memory again. Objects at that point, have the same foot print as almost any other structure because the code is not repeated - an object is essentially a placeholder for variables associated with a single reference point... the code is never duplicated. Even with inheritance, the base level class's code is compiled once, regardless of the number of derivative classes. So if you coded all the functions procedurally, your have the same amount of code as you would if you put them in a class. In fact, if you have two functions that do allmost the same thing but you had to duplicate the code, and you coul've done it in a tiny class hierarichy, you might have even saved a few bytes of memory. There is a tiny bit of overhead for class definition and reference points, but that is really pretty trivial.

The notion of putting EVERYTHING in a class is as silly, however, as avoiding OO because of overhead... there are just plenty times when it is either too big or simply the wrong tool for the job. Procedural

programming

  *definitely* still has it's strong points and I use a healthy blend of both - in every language I work with. CAVEAT: I am not talking about GUI client side apps written in C++ or Delphi now, only web apps written in combos like

PHP

  and JS. Clearly, if you write in Delphi, for example, EVERYTHING is maintained under a primary application class which gives it the necessary components to operate under the OS.


/p