I don't usually start threads, nor do I do it at forums where people usually seek for help but I couldn't help it.
Later today I got involved in a discussion where one fellow developer claimed that OOP in PHP sucks and is pointless compared to C++ and that PHP scripts should be done procedural way.

His statement kinda shocked me since I use OOP for separating layers of my PHP scripts (database handling functions such as connecting and reporting errors etc, session handling, template handling and such).
I never used something because I can use it so I'm careful when it comes to deciding what should go to a class and what should be done the procedural way.

I am aware that PHP doesn't have certain OO functions implemented (I used the word "functions" in lack of a better word since I'm not a native english speaker), but I was under the impression that OOP was first way of thinking, not the way you can DO something.
Also, I thought that OOP was created to put variables and functions that process them into the same place and to provide reusability, maintainability and code clarity.
Without fancy words - to make the code look more intuitive, somewhat shorter and easier to maintain (add new functionallity, remove deprecated stuff etc.).

I also saw alot of generally available PHP scripts that use OOP all the way, even though OOP isn't suited for such case IMO (for example, I saw a script that used a class to implement 3 methods: header(), middle() and footer() and all 3 just echoed some HTML).

So, why did I start this topic actually? I wanted to read what other developers had to say about OOP, especially WHY was it created and then where/when do you guys use OOP (if you use it)?

I certanly am not trying to compare C++, Java or any other language to PHP since I really don't want to start a flame war, I just aim to see what other people think about OOP in PHP.

I think the OOP in php4 and below is really poor, it seems clear that it was an after thought. So I would agree that OOP in PHP4 "sucks and is pointless compared to C++", but the OOP in PHP5 for the most part is nice. There are still some issues with it though. Since PHP is very weakly typed you can't cast objects, where as this is something you generally do. Also PHP lacks any notion of a "package", I find this to be the most annoying thing about PHP5.

I haven't looked into the history of OOP languages much but from what I know it was mainly created to deal with various issues in software development. That is OOP languages give you a better way of managing large projects.

I generally use OOP for most of my projects both on the web and else where. In fact even when I use a language like C I structure things a bit as if it was an OO language. But some things just aren't natural to express as objects. For example for things like compilers thinking of them in terms of functional programming, is the most useful to me. Here I mean true functional programming in languages like ML, where functions are first class objects and you have datatypes etcs.

But debating about whether you should use OO or procedural programming styles is pretty pointless, you should use whatever style you are most comfortable using.

Let him think OOP is pointless. That's fine. When you get good at writing OOP you can handle adding that new value to the database and it doesn't take you days upon days of writing out all that procedural code to add one field to the forms, to the listing pages...etc...etc

I fail to how OOP code is going to make things like database access faster to deal with. If you know how to write good procedural code, you are going to be able to make changes to it with just as much effort as good OOP code. The only real argument in favor of OO languages is that they make managing large projects a bit easier.

I'm not a big fan of OOP, but if there is something that gets repeated a lot, I'll just write a function for it and call it when ever I need it, instead of copy and pasting the same code over and over. But unless I'm going to use a "section" more than once, there is no point in OOP IMO.

Actually, having said that, occaisonaly I do become a neat freak with my code. If I have a nice looking file, and then I need 20 lines of not so nice looking code for something - I sometimes put those 20 lines in another file, make it a function and call it from my neat file :D

Wow, I'm suprised at the number of people not into PHP OOP. I'm really suprised that people don't see the reusable and cleaner code advantages that OOP can bring.

Here's a brief example.


$year = 2005;
$data = $bo->getAbstractList( $year );
$hide = array(
'ID',
'PreferTime',
'Specialty',
'Institution',
'Score',
'Body',
'DateEdit',
'EditDone' );

$results = $bo->hideFields($data,$hide);

$this->savant->assign('count', $bo->getCount($results));
$this->savant->assign('results', $results);
$this->savant->display('basicView.tpl.php');


With this code I can reuse all of the various functions very easily. The code is clean and if I have a problem with the count displayed on the page I can see I need to go to the $bo to check on that. The template code is completely separate. This code generates a list of 163 results and displays them listed in a table with all about 8 fields shown (you can see which fields are not shown due to the hide list).

Not only that, but using things like singleton patterns to make sure you only get one instance of some part of your code (for instance a db handler or config array) really helps performance in code.

To each their own I guess, just don't knock it until you've really given it a full trial. I've not met anyone that didn't prefer OOP once they figured out how to use it. There is a learning curve though. I'm still working through it to get a really good FrontController setup in a project.

Your example doesn't show that the OOP code is easier to deal with. Also I've programmed for years with OO languages (Java, C++, ocaml), and I don't always prefer OOP. OOP does not fit every solution. If you are working with mathematical structures that are defined inductively OO makes little sense (and you do such when for example you work with compilers).

Also Prodecural code can be writen just as well as OOP code. You can write reusable modular prodecural code. Its really a matter of what you are most comfortable using. I do think it takes a bit more talent to write good prodecural code though. Where as OOP tends to force some 'good' habits.

OO languages also make large project management easier...but no project you are doing by yourself is going to get that size (well maybe if you work on it many years).

my personal yodaism - OO does not a good programmer make.

You can write OO code just as sloppy and convoluted as a massive procedural monolith with no structures or function calls. In the OO case it becomes too many layers instead of too few. I have seen literally 6 or more layers of inheritance all for the sake of avoiding the duplication of less than ten lines of code which are not very complex in the first place. Too many OO programmers get caught up in UML glory mode where they create these massive trees of classes without thinking about how the cod ewill be to read for someone who does not need or have the architecture view. As was also mentioned you have certian low level system concepts which dont readily lend themselves to objects.

That said there are places where OO is the only way you can save a complex system from deteriorating into utter chaos - especially if there is more than two or three developers on the project. There are also some projects which just naturally lend themselves to OO. One is games. A sprite or polygon is natural to think of as a thing that has certian characteristics and certian abilities. eg: rocketship.shoot(target); is much more intuitive than shoot(rocketship,target); On a basic level OO is good because it imposes a sense of orginization on your work but as was also said you can write well organized non OO code it is just verb->noun rather than noun->verb and takes a bit more discipline.

Originally posted by nnormal
You can write OO code just as sloppy and convoluted as a massive procedural monolith with no structures or function calls.
it's gonna be harder to write sloppy oo imho

im not too sure why people who support procedural code (i.e. the use of functions i am assuming) are not supporting OO code and vice versa because the advantages of using functions and classes are the same. They both promote reusability and managibility. Toilet code on the other hand, is just downright idiotic.

Those who don't support OO don't support it because it's slow and inefficient. The whole point of programming in C is the fact that C allows you to go directly at the data through relatively low level operations. Adding OO is just more overhead. I think OO should be contained to java application where there really is no expectation of speed.

Those that don't support OO because of speed are going off extremely outdated rumors. The proformance of C++ and C are pretty much the same. C will do a bit better on some things, but then C++ will do better on other things. Usually the profermance difference in either direction is just a few percent. Also the view that Java is slow is extremely outdated, its performance is just a bit behind C++. Java applications will take up more memory, but this is often because people don't restrict the amount of memory the VM uses.

In fact to say that OO is slow doesn't make much sense, after all they are all compiled to machine code in the end. So the question really is which compilers are better. The issue between C and C++ was a compiler issue! The C compiler was much more sophisticated when C++ first came up..but that has long since past. And you see differences in performance because procedural and OO languages give the compiler different information. Sometimes the compiler is able to make better choices about optimization when the code is OO and at other times if its prodecural. Anyhow so the real issue is OO compilers vs procedural compilers not OO vs prodecural languages per se.

The only real consideration when thinking about which programming style to use is...what you are more comfortable with.

Originally posted by Froggy
[B]Those that don't support OO because of speed are going off extremely outdated rumors. The proformance of C++ and C are pretty much the same. C will do a bit better on some things, but then C++ will do better on other things.


Care to provide some examples. This is highly ambiguous. C++ is code bloat and just adds more data to the stack.


Usually the profermance difference in either direction is just a few percent.


I dispute this. Compare Cocoa OO apps to C++ applications. I'm not sure if this is still the issue but it used to be that you had to run sprites through opengl or you would have intense lag with 50 moving sprites on the screen.


Also the view that Java is slow is extremely outdated, its performance is just a bit behind C++. Java applications will take up more memory, but this is often because people don't restrict the amount of memory the VM uses.

Is that why Doom, Halo, and Halo 2 are coded in C? Well you tell me that's different. And I say exactly. That's the reason you choose C because it performs well under all conditions. If compilers are truly getting that much better it just means that C will be that much faster than Java.

What sense is C++ "code bloat" the machine code produced is not any more "bloated" than that produced by C. Also what are you asking for examples of? Benchmarks? I can post some of those if you'd like but you can find tons by just googling the topic. For example:

http://unthought.net/c++/c_vs_c++.html

The OpenGL is a prodecural API...all graphics APIs are because they have to interact with low level graphics hardware. This is a case where OO does not make much sense.


Is that why Doom, Halo, and Halo 2 are coded in C?


Are you asking why they don't use Java? If so because Java is still a bit slower than C++/C and for games like Doom 3 that extra 3-4% in performance actually makes a difference. There also are not nearly the amount of resources for Game development in Java as there is in C/C++. Also I have no doubt that if you wrote a gama in java it wouldnt' be popular because of rumors about Java that haven't been true for years. You can write games in Java though and people have, there are OpenGL bindings for Java. For example:

http://lwjgl.org/


Also the technology used by Java is newer and is still developing. Its very possible that things like garpage collection end up leading to higher performance. So considering Java and C are based on very different technologies, I don't see how Java doing better is going to effect what C compilers do at all. People once resisted C as being too "high level"...they are doing the same with things like garpage collection.

Originally posted by Froggy
Are you asking why they don't use Java? If so because Java is still a bit slower than C++/C and for games like Doom 3 that extra 3-4% in performance actually makes a difference. There also are not nearly the amount of resources for Game development in Java as there is in C/C++. Also I have no doubt that if you wrote a gama in java it wouldnt' be popular because of rumors about Java that haven't been true for years. You can write games in Java though and people have, there are OpenGL bindings for Java. For example:

http://lwjgl.org/


Also the technology used by Java is newer and is still developing. Its very possible that things like garpage collection end up leading to higher performance. So considering Java and C are based on very different technologies, I don't see how Java doing better is going to effect what C compilers do at all. People once resisted C as being too "high level"...they are doing the same with things like garpage collection.

You've got to be kidding me. Doom 3 would only be 2 to 3% slower on Java? You're insane. Try 50 times slower. You see this is where you fail to appreciate the specialized programmer. The specialized programmer writes code that is closer to the hardware and performs better than any interpreter. An interpreted language is always going to be an interpreted language no matter how you dress it up.

Besides, the java opengl libraries aren't even cross platform. What's the point? You're better off to write something in allegro.

My first post for half a year :)

From my experience OOP can be both useful and not.

In most cases OOP represents business logic. For example, if you are a developer in a big company then classes are used to define common business logic which is used across the applications.

OOP also groups functions by functionality: database class, search class, caching class, etc.

Classes require a lot of maintenance if they are not designed well. If you develop applications in the environment were logic is changing often, there is no need in OOP. In these cases OOP is only useful for helper class methods which don't require any logic and just encapsulate reusable code.

For example, there is a construction company. To get divisions and communities you would use this code:

$div = new division;

$div->getList();

$com = new community($divisionID);

$com->getList();

You've got to be kidding me. Doom 3 would only be 2 to 3% slower on Java? You're insane. Try 50 times slower.


I have no idea how much slower it would be on Doom 3, nobody has tried to make a game like that on Java. I see no reason why it would be something like 50% slower though.


You see this is where you fail to appreciate the specialized programmer. The specialized programmer writes code that is closer to the hardware and performs better than any interpreter.


This is where you fail to appreciate the sophistication of "interpreters" in general. Please note that sophisticated "interpreters" will do hot compilation. Sun's VM has done this for some time now. Also the interpreter has much more knowledge about what system it is running on...than the programmer does.
So when you do hot compilation you can take advantage of this extra knowledge to make better optimizations in the code, this is a pretty new technology and is getting better and better. Futhermore compilers/interpreters in general can do much better code optimization than programmers can. Its a very bad programming practice to try to optimize code before you do benchmarks etc etc. Its very rare that you'll need to write some cryptic low-level C code (or routines in assemly) to get better performance.


An interpreted language is always going to be an interpreted language no matter how you dress it up.


You really need to look at what has been done with "interpreted languages" in the last 10-15 years. They are extremely sophisticated.



Besides, the java opengl libraries aren't even cross platform. What's the point? You're better off to write something in allegro.


Its much easier to deal with cross platform issues. Although you can't have one single DL for all platforms, all you need to do is make different packages for the platforms you want to use that contains the Libraries for the OPenGL bindings. This is much easier to do than port C/C++ from say windows to linux.

You can use AllegroGL to port windows to linux. My point is we shouldn't be limiting ourselves no matter how fast our hardware gets. Imagine if each application on your system ran 5% slower. That would be horrible.

I'm not sure about fragfest games like doom/quake/halo but every game dev position I've applied for required x years of OO C++. It is true that some aspects of games are written in a C style but usually only routines which happen thousands of times a cycle eg polygon collision. In fact stuff like this is often written in assebler but you call it though a class. You are not writing the top level elements like the UI in assembler. As you get closer to the top you can afford to be less conservative about the resources.

One example of this is World of Warcraft. This game actually pushed the entire UI out to a Lua interpreted scripting language. This lets users tinker with the UI without effecting any of the low level C/C++ code and also gives devs an easy way to play around with the UI the way you can play around with something like HTML. how does this relate to OO? It's all about being able to maintain your code base. Even hardcore game devs know the value of writing code that is readable and well organized even at the expense of performance. No one cares if you get 3 extra FPS if the thing is crashing every 5 minutes.

You can use AllegroGL to port windows to linux. My point is we shouldn't be limiting ourselves no matter how fast our hardware gets. Imagine if each application on your system ran 5% slower. That would be horrible.


Porting to linux from windows, is not trivial. Regardless I"m not saying here pepole should be using Java for game development. But I think the main reason here is lack of development tools not the speed differenece.

Also if each application on my system was 5% slower, its unlikely I'd notice. In fact when I've over clocked my CPU just 5-10% in the past I don't really notice a difference without doing a benchmark. For most applications it just doesn't matter.
But you don't write low level stuff in Java as that would break its "compile once run everywhere" philosophy. Most applications don't require any low level code though. Having an application run a bit slower is well worth it if it means you are able to manage the code better.

Don't you think Carmack would develop games for Java if they were truly worth developing? Carmack has said Java is slow.

http://www.javalobby.org/java/forums/t18003


Write-once-run-anywhere. Ha. Hahahahaha. We are only testing on four platforms right now, and not a single pair has the exact same quirks. All the commercial games are tweaked and compiled individually for each (often 100+) platform. Portability is not a justification for the awful performance.



He finishes saying he would probably prefer writing games in BREW, the competing mobile device game development platform, which can be used with C/C++, although he does give Java a thumbs-up because no other platform makes it possible to have working code so rapidly. BREW also has one fourth the market share Java has.



"The biggest problem is that Java is really slow," he said. "On a pure cpu/memory/display/communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advance. With Java, on most phones you are left with about the CPU power of an original 4.77 MHz IBM PC, and lousy control over everything."


Now I'm sure if Sun could do something about this they would. But the reality is that they can't. If John Carmack isn't the authority on efficiency and speed I don't know who is. Parts of Doom were coded in assembly.

Ugh, This is just pathetic. Not only do you give me fallacious arguments by "authority" you quote sources about a totally different issue. What holds for mobil devices doesn't necessary hold for PCs and verse vice.

If you want to show that Java is slow...find benchmarks that show it is slow and post them. But please only show benchmarks with the newer VM, the old Java VM's no doubt had performance issues.

But seriously if you don't like Java don't use it, I could care less. I never suggested that Java should be used for everything, RATHER I argued that you should use whatever language makes the most sense for a particular project. It is clear to me for various issues (such as Java requires more initial resources than others) that java is NOT the right choice for Mobil devices. Although, I would suggest that Java makes a lot of sense for common desktop applications like IDEs, word processors etcs.

Please also note that I never suggested people should write games in Java, I don't even know why you're talking about it. The post is really about web applications.

I

I have no idea how much slower it would be on Doom 3, nobody has tried to make a game like that on Java. I see no reason why it would be something like 50% slower though.


An interpreter is an interpreter. And it is written by the same company. This idea that you can write processor intensive games like Doom in Java is completely wrong. What I am arguing is that Java is more than 5% slower than C++. I would say that is the minimum in most cases.

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html


The authors test some real numerical codes (FFT, Matrix factorization, SOR, fluid solver, N-body) on several architectures and compilers. On Intel they found that the Java performance was very reasonable compared to C (e.g, 20% slower),


20% is a lot even if the authors of this research under state it.

And it just gets more pathetic. Did you read the article? Apparently not, the quote you are quoting is from benchmarks done in 2001. It was using Java 1.3 and P3s!

And like I said if you want to argue that Java is much slower than C/C++ show benchmarks that show this. But again show benchmarks that use the NEW VM ideally the 1.5 version but the 1.4 version is ok too.

I repeat I never suggest that one should write games like Doom in Java, what I did reject is the idea that this is some how out of the question. Its not. Also when all you have to say is useless tautologies like "an interpreter is an interpreter" ...I don't know what to say. Also technically speaking Java isn't an interpreted language and never was one. Java is first compiled into byte code, this technique is used for many languages. And its very possible once more research is done on these techniques that they end up giving better performance than languages that are compiled directly to machine code. What you are stating is mere dogma.

But again if you don't like Java don't use it.

Also technically speaking Java isn't an interpreted language and never was one.
Then again all programming languages have their code interpreted at some level... oh well.

And its very possible once more research is done on these techniques that they end up giving better performance than languages that are compiled directly to machine code.
Not possible in the general case, methinks. More like make them competitive with languages compiled directly to machine code, like what Java is coming around to.

It is sort of like saying that C/C++ compiler technology can reach a point where such compiled programs are more efficient than the same programs written in assembly language. If we assume a sufficient level of expertise, then the programmer is always able to be at least as good as the compiler (at optimisation), especially when they can review the improvements made by the compiler and apply them as well.

It is sort of like saying that C/C++ compiler technology can reach a point where such compiled programs are more efficient than the same programs written in assembly language. If we assume a sufficient level of expertise, then the programmer is always able to be at least as good as the compiler (at optimisation), especially when they can review the improvements made by the compiler and apply them as well.


Well, not really. When you do hot compilation you have access to much more information than the programmer has in general. For example the size of the cache in the CPU. This information is used to make optimizations that otherwise cannot be made. Of course you could say "Well the programmer could write code for computers running with a CPU with a L1 cache of 64 and L2 cache of 512 and 1 gig of system ram etc etc.." But this is obviously not practical. So there is some potential there that does not exist in the case you mentioned.

But also even in the C/C++ and assembly case what you said doesn't happen much in practice. Almost always the assembly produced by the C/C++ compilers is better than anything you're going to do. From my experience when you write subroutines in assembly a lot of thought has to go into it so it actually does better than the C/C++ output.

This went the wrong way, as I knew it will.
The original topic was about OO in PHP. I didn't stress enough that the person I was in discussion with was strongly convinced that OO SHOULD NOT be used if using PHP, ever. I brought up the matter of C++ wrongly (since as it is, OO in PHP cannot be compared to C++ nor was that the issue here).

For example, I use a class that wraps archiving functions. If I were to follow the logic of my discussion-mate (in lack of better word), I should do archive wrapping the procedural way which I personally find less-descriptive and less-maintanable than OO way.
I just wanted to see what other PHP developers do, not Java/C++.
If you find this topic still interresting enough and if you are willing to write something, please do so.
Is OOP pointless in PHP because of lack of features?

I personally believe that it isn't, but it should be used with care.
Another disappointing thing is that a lot of people that come across PHP and it's OO capabilities think instantly how "Classes RULE!" and do their scripts ENTIRELY OO (with some minimal procedural code routines, to invoke base objects) and I find it as bad since it kinda brings PHPs reputation down because they are mostly used the wrong way.

I don't even think you can do real OOP in PHP4, due to the lack of features that are so important to it. When I use PHP4 I just code in a procedural style.

Where as PHP5 has enough features in the language to make real OO design possible. Also I tend to think php people think OOP means "making classes" and that is just part of the story. Although I'm starting to see various common/long standing OO design patterns becoming popular in PHP, or at least people are talking about them.


But in the end for PHP I don't think it matters that much. You can write good managable procedural code, but in practice it does seem to be pretty bad from my experience = /

Well is lack of features reason enough to ditch PHP 4 OOP completely? I'm in a conflict here - is OOP way of thinking first and then the way of writing your code or vice-versa? I thought the first is the case..

Yeah its mainly a way of thinking, but if the language doesn't support that way of thinking than it makes it much harder to do it.

For examply PHP4 copies all your objects when you pass them etc, this behavior is not very natural and with the case of returning functions its a pain to deal with you have to remember to return and assign by reference. Also there is a lack of data encapsulation which fundamental to OO design.

I don't use PHP4 any more, but most shared hosts are still running PHP4, so you'll need a VPS or dedicated server to use it. But if you are able to write good modular code in PHP4, then why change what you do?

Eh, I wouldn't change the way I write my code now, I was merely wondering on other people's oppinion about this matter.
I agree that PHP 4 suffers of too many ampersands :) but once you get used to using/writing them - it's no hassle.

Originally posted by Froggy
Yeah its mainly a way of thinking, but if the language doesn't support that way of thinking than it makes it much harder to do it.

For examply PHP4 copies all your objects when you pass them etc, this behavior is not very natural and with the case of returning functions its a pain to deal with you have to remember to return and assign by reference. Also there is a lack of data encapsulation which fundamental to OO design.

I don't use PHP4 any more, but most shared hosts are still running PHP4, so you'll need a VPS or dedicated server to use it. But if you are able to write good modular code in PHP4, then why change what you do?

OOP is really a way to organize and handle things. If you want to be organized, use OOP, if not, do whatever, not my code, I don't care. :D

Really I don't have a problem with procedural code. Some people like it... I don't... we're different, and that's O. K. :)

PHP4 handles OOP quite nicely for those just looking to organize their code. If your looking for optimizations, that is something else entirely. I've never encountered a problem with references being an issue (aside from optimization techniques), as it seems 'dirty' for a function to modify data passed to it. Maybe that is just me again though.

:topic: You don't actually have to have a vps or dedicated server to use PHP5. There are quite a few hosts who support php5, or even dual php4/php5 if that is one of your hosting requirements.

as it seems 'dirty' for a function to modify data passed to it. Maybe that is just me again though.


Its dirty if that data isn't suppose to be modified, but a better option for that is making an object that is not mutable (which can be hard in php4). But often you want to have a single object that can change and those changes will be visible to everyone that cares. PHP5 does the opposite as PHP4 - by default it passes references you have to explicitly clone an object to get a copy.

Also the continuous copying of object is going to be a performance problem for all but small scripts.

OOP is a way of thinking. So even if a language is not fully object oriented in nature the design can be. I've never coded in PHP but have been implementing OOP techniques in classic ASP for many years. I list some of the Pros and Cons as I see them on the following thread...
http://www.webhostingtalk.com/showthread.php?s=&threadid=297232

The mention of ASP is not meant to start an ASP vs. PHP (or anything other language) discussion. I simply mention it because if I find OOP useful in classic ASP I'm sure it is useful in PHP.

I don't think its possible to write real OOP code in languages like PHP4 and ASP. I think what you are talking about is object based programming. Which is much more simple...you can do object based programming in php4 etc.

The key features to OO are: encapsulation, polymorphism and inhieritance. PHP4 pretty much can't do two of these and can do the other a bit. Where as PHP5 can do two of them without a problem but has issues with polymorphism (you can do it...but its very unnatural, but this is due to the lack of types more than anything).

Without having these features available in a language I don't see how you can write real OO code in with it. Of course you can always do the initial layout of the project via OO, but if the language doesn't support it then you're going to have to translate the OO stuff into that language.

Anyhow so I think the real question on this thread should be is:
object based programming useful etc.

While it is true that a language that fully supports OO will include abstraction, encapsulation, polymorphism and inheritance, if a programmer doesn't make use of those features they would not be using OO. In other words, a person can use Java and still put all their code in one class with one method. Does using Java make them an OO developer? No, it is in the implementation - the way they think.

In my case I started with VB6 and ASP(with vbscript) - neither of which is fully OO compliant. But I still took an OO approach. Now that I do use a fully OO compliant language I take advantage of things I did not have before, such as inheritance. But I was able to port my code and framework easily because I was already thinking in objects. So I completely agree with the OP when they said they thought...
Originally posted by maxymizer
OOP was first way of thinking

But I was able to port my code and framework easily because I was already thinking in objects.


My point again is that thinking in objects is NOT thinking in OO, its thinking in OB (object based) programming. There is a pretty big difference.

I guess you will have to define the big difference between thinking in OO and in objects because it is one and the same to me.

Would anyone else use the term Object Oriented and Objects in the context of this post to mean different things?

You can find the definition of object based programming here:

http://en.wikipedia.org/wiki/Object-based_programming

Object oriented definiton at:

http://en.wikipedia.org/wiki/Object-oriented_programming

Certainly one of the major parts of object oriented programming are objects, but this is just part of the story. Object based usually only has a notion of object but lacks one or more of the other fundamental components of OO.

PHP4, lacks real inheritance, polymorphism and data encapsulation all these are fundamental features of OO and without just one of them you aren't really doing OO. PHP5 really only has problems with polymorphism so its really close to being a true OO language. I think its as close as you are going to get so long as PHP lacks typing.

So if all you are doing is organizing your code into "objects" then you are doing object based programming. On the other day if you are thinking about which data should be accessible, object hierarchies etc then you are doing OO.

I really do not think Object-based programming gives you that many benefits, as a result I prefer to write procedural code in languages like PHP4. On the other hand I find object oriented programming very useful.

Thanks for the insightful reply. Now I understand what you mean by object-based.

I guess it has come down to a matter of preference. Because, while we both understand that you don't get full OO capabilities with scripting languages, I prefer to use object-based programming - limitations and all - in such environments while you'd rather switch to procedural. Neither style is necessarily wrong.

PHP does not copy implicitly when you pass an object. It passes by value, which is very different in modern interpreted languages than it is in C. The interpreter does copy-on-write (much as many OS MMs these days do). The only time you need to explicitly pass by reference is if you need to mutate the object. This almost makes more sense than always passing references, since functions can only have side-effects if you explicitly allow them to, especially for inexperienced programmers (that happen to be coming to PHP in droves).

In any case, the whole pass-by-reference thing is rarely a perfromance issue unless you're in the habit of making discardable modifications of objects in every function.

If any feature is *the* fundamental tenet of good OOP, it's polymorphism. If PHP4 isn't good enough because it lacks features, nor is PHP5 (according to you, AFAIK PHP5 does polymorphism just as well as Java does, with PHP4 even supporting very basic polymorphism). Obviously you can't even claim OO support without at least basic inheritance, so I'm not going to count that as an OO 'feature'.

Now, on topic.

PHP4's OO is definitely a good thing. Yes, it's crippled. No, it's not nearly as powerful or sufficient as Java's. Regardless, it still promotes well-structured code, and definitely helps organize and maintain larger projects. It reduces bugs and makes code easier to follow. You keep bringing up Java where it's not even in consideration. Is PHP4 OO a good idea? Certainly. Does Java or its OO features matter on iota? No.

PHP4's OO is definitely a good thing


PHP4's OO doesn't exist. You can't do OOP in PHP4. You can on the other hand do object based programming.

PHP4 is lacking in very major feature of OOP, I don't know how someone can pretend to do OOP in it. I think usually people just confuse object based programming with object oriented programming.

I've also not seen that object based programming helps organize projects. I see just as much bad object based code as I do procedural. You should use whatever style you are most use to thinking it.

Originally posted by Froggy
PHP4's OO doesn't exist. You can't do OOP in PHP4. You can on the other hand do object based programming.

PHP4 most certainly has OO. You make grandiose claims that it has no inheritance, polymorphism, or encapsulation. Only the latter is true. While the features may not be as powerful as they could be, they definitely exist. I'm not even quite sure were your complaint about its inheritance lies; I don't do too much in PHP, but I've never had any issues with class hierarchies. The feature seems exactly what you'd expect from an 'extends' keyword. What's missing, exactly (besides interfaces or multiple inheritance, which are not fundamental to OOP)?

Polymorphism is indeed weak, but it definitely exists. Since the language is dynamically typed, polymorphism is almost implicit. But the type-checking functions allow more fine-grained control that works as you'd expect of an OO language.

Encapsulation certainly isn't there, but this is the least important of the properties on your list. You can easily write OO code without it if you just avoid accessing 'private' members. This is less-stable and allows for some stupid ****, but it doesn't prevent you from adhering to OO methodologies.

Yea, PHP isn't a paragon of OO language design. We get it. But the OO features that exist are useful, and are powerful enough to make it beneficial to write OO code (and yes, you certainly can).

I seriously don't understand your claim. You admit that PHP4 is lacking in all the fundamental features of OO yet claim you can do OO in it...that is odd.

PHP4 lacks abstraction and encapsulation this in itself is enough to make it so you can't do real OOP in PHP4. But its worse than that..as its ability to deal with polymorphism and inheritance are lacking too (although somewhat there).

Claiming that you can do OOP in PHP4 is just as silly as stating you can do it in a language like C. C also has SOME features of OO languages, but this doesn't make it OO.

You can do object BASED programming just fine in php4 and that is what people do with it.

It's not that complicated. The features are lacking, not nonexistant. Objects and inheritance coupled with polymorphism (in this case not-really existant, but not-really relevant since the language isn't statically typed) are enough, in most modern languages, to write code that is fully OO. C does not have either of these concepts (since structs can't have methods). PHP has both, along with quite a bit more in the way of object functionality. Encapsulation in the language forces you to 'be good,' but by no means is it impossible to implement encapsulation in PHP if you just don't break the rules. Write getters and setters, and use them. It's really not difficult to get used to, just refrain from accessing instance members directly. I fail to see how code written this way is somehow not OO simply because the language doesn't force it to be. If I write identical classes (ie. with the same interface) in PHP and Java, and use them with the exact same calls in a code snippet, how can you seriously tell me that the Java implementation is OO, while the PHP version is not? OO is a paradigm, while it depends somewhat on language features, it's far more about design. PHP provides more than is necessary to write OO code, it just doesn't enforce good OO practices, and makes you (or your IDE) do some 'bookkeeping' (ie. of return types, access control etc.).

If a programmer never touches internal members, even though he could, he's writing OO code. The language has nothing to do with it; the fact that Java et. al. have tools to enforce this is a simple usability feature, not a functional one. Encapsulation is important to OOP, yes, but it doesn't necessarily have to be enforced by the language. Abstraction (if, by that, you mean the existence of abstract classes and interfaces) is, for the most part, irrelevant due to the way the language handles types. If you want to, you can define a class with empty methods, extend it and implement, and then do runtime type checking on your instances to make sure they adhere to the interface. Lame, yes, but fully OO and fully doable if necessary.

How you can say it's impossible to write OO code in PHP is beyond me, since there is such a huge amount of such code out there, and since it's rather obvious that while the language doesn't enforce as much as many other languages, almost any basic OO technique can be used fairly easily in it. The biggest lacking feature that affects functionality (rather than usability) is the lack of multiple inheritance or interfaces.

The features are lacking, not nonexistant.

No two are missing. You just happen to not find one of them that
important, but so what? My guess this has more to do with your
lack of experience with OOP languages than anything else.

Again if a language doesn't support all of the features of OOP at least to a decent degree you simply cannot write TRUE OOP code in it. PHP4 at the very least lacks two: abstraction, encapsulation. I think you are just equivocating "Object oriented" with "Object based".

Also..with encapsulation. This is a fundamental feature that is highly relevant to software development. Relying on the user of a package or class to "be nice", is a very bad idea. Its much more deep that not giving access to particular instance variables. You have for example private/protected methods. Also encapsulation is really fundamental to the notion of an "object" in the first place.

Also my point about C is this: it has features of OOP languages, NOT the same features that PHP does. You CAN have abstraction in C you CAN have encapsulation in C. You also have inheritance to a limited degree.

It's not due to my lack of experience, it's due to my lack of Java brainwashing. Your irrelevant, arrogant arguments are getting rather annoying.

You can write OOP code in PHP4 just fine. Encapsulation is a concept that doesn't require any language features; it requires a mindset and a diligence in coding, whether the language forces such or not. Abstraction in the same vein; define an interface and follow it. It's not that difficult. The fact that the language doesn't enforce this is irrelevant. It's still an interface, and your class still provides it. These concepts don't *have* to be implemented in-language for them to be applied to the code.

You could conceivably write OOP code in C, it would just be incredibly hairy and more difficult to follow than a traditional procedural apporach (most of the time). PHP provides enough functionality that it's entirely feasible, easy and worthwhile to write OO code where appropriate.

This is way offtopic now and I'm not arguing about it any further. Methodologies are far more about how you think about a problem, and your approach to solving it than they are about language features.

Originally posted by Froggy
My guess this has more to do with your
lack of experience with OOP languages than anything else.
...
I think you are just equivocating "Object oriented" with "Object based".
This argument has nothing to do with experience. I think you are just being too dogmatic about this. If you want to be technical, the wikipedia definition you posted for object-based says it is "A somehow limited version of object-oriented programming". So one would not be wrong to call object-based programming object oriented - it is just a limited version of it.

That said, let me echo error404 words...

This is way offtopic now and I'm not arguing about it any further. Methodologies are far more about how you think about a problem, and your approach to solving it than they are about language features.

Originally posted by Froggy
No two are missing. You just happen to not find one of them that
important, but so what? My guess this has more to do with your
lack of experience with OOP languages than anything else.

Again if a language doesn't support all of the features of OOP at least to a decent degree you simply cannot write TRUE OOP code in it. PHP4 at the very least lacks two: abstraction, encapsulation. I think you are just equivocating "Object oriented" with "Object based".

Also..with encapsulation. This is a fundamental feature that is highly relevant to software development. Relying on the user of a package or class to "be nice", is a very bad idea. Its much more deep that not giving access to particular instance variables. You have for example private/protected methods. Also encapsulation is really fundamental to the notion of an "object" in the first place.

Also my point about C is this: it has features of OOP languages, NOT the same features that PHP does. You CAN have abstraction in C you CAN have encapsulation in C. You also have inheritance to a limited degree.


You are just throwing big words out there and keep repeating yourself. Stop taking this thread off topic. You say yourself that you cannot see how OOP in PHP4 can be done or why. I see this as your lack of PHP skills and knowledge.

Back to topic. OOP in PHP4 can be done and it should be done when it makes sense. Some things that simply call for it are templating engine, shopping cart, user management. Often out-of-school programmers will try to do everything in PHP using objects and classes which is overkill and not called for. Some people will totally ignore OOP side of PHP at their own loss. The reason for that is that they are brainwashed into Java way of thinking or that they never did any large web applications when monolithic way of doing things makes everything overwhelmingly huge and non-reusable.

it's due to my lack of Java brainwashing.
My comments have nothing to do with Java, I was speaking about OO languages in general.


Encapsulation is a concept that doesn't require any language features

errr...huh? Yeah encapsulation doesn't require any language features. Like how PHP4 makes all your data available that is clearly encapsulation (oh but wait you can make get/set methods...err what about everything else?) I wonder why they added it in PHP5..hmmm.


I find the comments funny...like "using objects and classes".
This just seems to go over peoples heads I have no idea why.
Object orient programming is NOT just "objects and classes" that is
object BASED programming. And yes object based programming is in a sense a limit sort of object oriented programming this does not mean it is object oriented programming. Saying PHP4 is an OO language is just false.

But yes Sun has brainwashed people into the "Java way of thinking" seriously what is that?? Apparently Object orient programming is now Sun's brainwashing..nevermind the fact that other languages use it (C++, ocaml...etc)

But yes sure you can do OO code in PHP4 <wink> Seriously if any of you are actually employed....I pitty the people that have hired you.

Sure, I've written OOP code in C, simply by using OOP notation style and malloc/free cycle. It's not a very efficient use of programmer and maintainer time, but you can do it. Some kids with no perspective were claiming that Java is noticeably slower than C, but that's an extremely naive POV.

Of course you can create more efficient code in C than in Java, but generally you have a set amount of time to write your program, and with C, or PHP for that matter, you have to write an amazing amount of really basic code (think Collections in Java) yourself, and the results are often less than optimal because of the limited time available, and you have to debug all of that utility stuff yourself.

When writing serious software with an adult software development team, the most efficient use of the team's time is achieved by using a system which provides a constant, common and complete conceptual framework, which has a reasonably efficient default implementation and which you can optimize within that framework where optimization is required.

You'll understand when you grow up.

http://dictionary.reference.com/search?q=condescending

Wow mikaelhg, you're just all sorts of wrong. Malloc/free cycle?? What does garbage collection have to do with OOP? And could you please explain to me what OOP notation is? Listen sweetheart, maybe some of the *kids* on this post are somewhat incorrect in their interpretation of what OOP actually is but you are just completely lost.

I don't dislike Java by any means and I believe it has it's uses, but it is slow, like little yellow bus slow, and has little advantage over it's natively compiled couterparts, e.g. C++, aside from it's 'write-once run-anywhere' ability. In fact, developing can be more time consuming in Java when you factor in the effort spent continually optimizing code to improve it's inherently slow performance. True, C++ has no gc but with a good debugger and decent coding practices memory leaks can be virtually non-existent, and if discovered can be isolated and repaired relatively easily.

BTW - I'm thinking 'collections in Java', and I guess I'm just not seeing it.

I don't dislike Java by any means and I believe it has it's uses, but it is slow, like little yellow bus slow, and has little advantage over it's natively compiled couterparts, e.g. C++, aside from it's 'write-once run-anywhere' ability. In fact, developing can be more time consuming in Java when you factor in the effort spent continually optimizing code to improve it's inherently slow performance.


This is just absolute rubbish. These are mere rumors about Java that were only partial true years ago and haven't been true for many years. Java is not much slower than C++, here I"ll say it again Java is not much slower than C++. Java even will out perform C++ in some things. Although a large project writen in Java is going to be slower, but not much slower (at most 10% or so). And ugh....development in Java takes much less time than development in C++. Furthermore when it comes time to do optimizations in your project the optimizations if anything are going to be faster to do in Java (and please note you'll need to optimize C++ just as much as you will Java code). But no doubt you have more control in C++ and this makes it more suitable for some tasks.

Also your comments about memory leaks show you've never worked on a large project in C++ or C. Memory leaks are non-trivial to deal with, there are many examples of projects that have died due to memory leaks that could not be tracked down. Once the code base gets large memory leaks become extremely hard to track down.
So when developing a project in C++/C you need to do unit tests on each piece of code so you can catch memory leaks locally when possibly, but this adds a lot of developoment time to your project. Furthermore it doesn't mean you aren't going to have memory leaks when everything is working together.

This is just absolute rubbish. These are mere rumors about Java that were only partial true years ago and haven't been true for many years. Java is not much slower than C++, here I"ll say it again Java is not much slower than C++. Java even will out perform C++ in some things. Although a large project writen in Java is going to be slower, but not much slower (at most 10% or so). And ugh....development in Java takes much less time than development in C++. Furthermore when it comes time to do optimizations in your project the optimizations if anything are going to be faster to do in Java (and please note you'll need to optimize C++ just as much as you will Java code). But no doubt you have more control in C++ and this makes it more suitable for some tasks.

Perhaps I should clarify, many low level non graphical calculations can be performed by java with little or no performance losses when compared to C++. When GUI's come into play, though, it is a different story, even with the advancements in the VM and computing technology in general. As far as development time, I think C++ and Java differ very little, but this is due largley in part to RAD environments. I could develop an app in Borland C++ Builder or VisC just as quickly as I could in J-Builder, and in a team environment this should be no different, as long as proper plans are laid and conventions are adhered to. Although I will admit that developing a *graphical* C++ app without an IDE is rediculous and it this case I would choose Java, but unless you're a masochist why would you ever be faced with this decision.

As for memory leaks, C is more prone to them but Java is not immune either, and properly trained developers, coding standards, and testing/debugging practices can eliminate them in either language. I will say that you can get away with sloppier code in Java, thus making the planning phase less critical, but that is just stupid and shouldn't be acceptable in any language, and certainly not in a team.

More myths.

Java GUIs are not slow...Swing is not slow. GUIs in java are going to be a bit slower, but not much. And with GUIs it really doesn't matter, they are the sorts of things where speed is not the main issue.
Its just as easy to make a slow crappy GUI in C++ as it is in Java, in fact GUIs are easier to make in Java. The only issue with Java apps is treading, you need to have a decent understanding of it to write non-trival java GUIs.

Do you have a particular Java application in mind that is slow? Whenever I've seen a Java GUI app not respond fast it was a threading issue.

Java also has all sorts of IDEs for it that speed up development, that are just as good as the ones for C++. Java remains faster to develop in because you do not need to deal with memory issues. These issues in themselves take up a lot of planning and testing time. Debugging is also harder in C++ than it is in Java.

hmm... but the question here isnt Java vs C++...

Wow, you're one of the outnumbered here who actually read the topic.. :)

Wow, threads change topics.

an interesting discussion of OO in the field of UNIX programming which seems closer to where the topic started (PHP).

http://www.faqs.org/docs/artu/unix_and_oo.html

"Since the mid-1980s most new language designs have included native support for object-oriented programming (OO). Recall that in object-oriented programming, the functions that act on a particular data structure are encapsulated with the data in an object that can be treated as a unit. By contrast, modules in non-OO languages make the association between data and the functions that act on it rather accidental, and modules frequently leak data or bits of their internals into each other.

The OO design concept initially proved valuable in the design of graphics systems, graphical user interfaces, and certain kinds of simulation. To the surprise and gradual disillusionment of many, it has proven difficult to demonstrate significant benefits of OO outside those areas. It's worth trying to understand why............"

Originally posted by Froggy
Wow, threads change topics.

Wow, I wonder why.

I don't want to make this into total flame war so I'm stopping here. Please, try not to reply to this Froggy. Thanks.

Back to the original topic - lots of people that actually took part on initial topic think that OO in php (version 4) is not just a lame feature but that it provides what it's meant to provide.
This also confirms my thoughts that you don't need the biggest gun to fire a bullet, you can do it with any gun that provides basic means (bullet beeing OO, gun the language we use).
Thanks to everyone who found the time to share the thoughts on the matter.
Of course, there are people that rather disagree with my conviction, but that's the way it is.
I'm just happy that I'm not alone in my thinking :)

Yes you have a lot of people that don't understand OO or programming languages in general that are right with you in your thinking.

Originally posted by Froggy
I haven't looked into the history of OOP languages much but from what I know it was mainly created to deal with various issues in software development. That is OOP languages give you a better way of managing large projects.

I generally use OOP for most of my projects both on the web and else where. In fact even when I use a language like C structure things a bit as if it was an OO language.

Originally posted by Froggy
But debating about whether you should use OO or procedural programming styles is pretty pointless, you should use whatever style you are most comfortable using. Amen!

Originally posted by Froggy
Yes you have a lot of people that don't understand OO or programming languages in general that are right with you in your thinking.

Having read that from a guy who tried to compare Java and C++ in terms of performace really means nothing..also, you misunderstood what I wrote and it's either my bad english or something with your understanding of the same.
But anyways, I have my oppinions and you have yours. The only difference is that I won't try to "convert" people to my way of thinking.
I really dislike flaming, so I kindly ask you not to add oil to the fire anymore, if possible.

Tommar: what I meant by managing the malloc/free cycle in an object oriented manner in C was that I define structs for my objects, include all resource allocation references (object graphs) inside these structs, and then create constructor and destructor methods which handle creating and releasing of all of the resources which are contained on that level of the object graph and one level down.

That way, I can easily and separately test that each object can take care of allocating and releasing its resources, and be reasonably sure that those tests are valid on a systemwide level.

Is this clear?

Having read that from a guy who tried to compare Java and C++ in terms of performace really means nothing..


And the myths live on....

And the point of my comment is that: ALl the peole that say they do OO in PHP4 are people that don't have any idea what OO really is..they are thinking of object based programming. Whether someone uses object based programming or prodecural programming in PHP4 is a matter of personal preference. And this is what I said in the beginning I don't see how that equates with trying to "convert" people.

We are talking about two total different aspects Froggy. I just deleted what I was writing the last 15 minutes since it would lead to even more argues.

Just remember, OO IMO is a way of thinking first, and second - a language implementation. Even though PHP 4 lacks in implementation, I don't think that OO in PHP 4 should be ditched completely and that's what's it all about.

http://c2.com/cgi/wiki?DefinitionsForOo

There is no consensus on the definition of OO.

However, PHP4's implementation of OO is of less value than the utter lack of OO implementation in C, which at least didn't come in the way of the developer, slow the system down, and provide developer and library confusion.

http://c2.com/cgi/wiki?DefinitionsForOo



haha.. good call

However, PHP4's implementation of OO is of less value

I don't believe the developers of PHP4 were trying to give an implementation of OO, they at least know what they did isn't anything close to OO.

I don't believe the developers of PHP4 were trying to give an implementation of OO
I could have sworn that I read an article last week (in an interview with one of the key players in PHP's development) that stated that PHP (which includes PHP5, and eventually PHP6, I suppose) would never really be designed with OOP in mind - unfortunately I cant find it.