Function vs Class
Moderator: General Moderators
I use 'standard' functions in PHP more or less all the time but it doesn't mean the code is messy or can't easily be changed. I have a collection of seperate PHP files each containing a function.. an email sorting and sending function for example.. and simply include() the functions if and when they're needed. This way only the code that is required will be included in the pages.. which helps to keep the speed up.
Hi...
. Consider the pace of writing enthusiasm rather than aggression...please.
Quake 3 is a good example of this, adding it's own partly declarative language on top of the C core. By changing language the number of lines of code is kept below the number that triggers the need for strong encapsulation.

yours, Marcus
Sorry, I did not intend to be rude and apologies if I wasBDKR wrote:You now Marcus, that was a rather simple black and white response.
Well, I am first and foremost a C programmer so I know what you mean. Now C has functions as first class objects (albeit with pointers and the C type system) which makes it possible to do OO or functional programming to some extent. The fact that C can be bent this way does not make it the best solution, however. By comparison C++ is a hideously complicated language which makes C preferable for small projects. It becomes worth the extra expense of C++ developers when the code base gets beyond 30000 lines or so (in my experience). If you like the extra skill cost balances the the large project leverage you get from OO. I am not saying that it is impossible to write flexible systems with non-OO languages or less than fully functional languages, only that there is a cost involved in reduced flexibility. It is simply more work.BDKR wrote:I'm presently digesting the QIII engine, which is written in C FYI, and it's not tough to extend or change. Not to the point you make it out to be.
But bending a non-OO language into an OO one simply demonstrates the desirability of that quality. I have seen C chosen most often because of the lack of C++ experience (I do this too) or because of a lack of knowledge of more radical solutions (a domain language say) not because it is prefereable to use the simpler paradigm.BDKR wrote:...as much as the C language will allow that is.
Quake 3 is a good example of this, adding it's own partly declarative language on top of the C core. By changing language the number of lines of code is kept below the number that triggers the need for strong encapsulation.
OO does take a couple of years to get a handle on, but at that point I disagree. It is very much as clean as I make it out to be. The example I quoted was a grand total of three hours work (including tea breaks). Now the example was very suited to OO (no relational database involved for example) I grant you, but I am now well into the domain where my 3 years OO is more productive here than my seven of non-OO.BDKR wrote:This isn't as clean as you portray it too be.
Hm...I am in the OO camp for the PHP apps I do now, but I was not out to expouse OO as such. Simply I wanted to point out that rejecting OO for performance reasons was a bad choice. There are reasons for rejecting OO, mainly when encapsulation is going to cause trouble. For example if there is a large amount of configuration or you are interfacing with a system that uses it's own language or there is very little state in the system. All of these will cause development overhead if done with OO.BDKR wrote:You've just raised the same old battle cry that other dedicated OOP'rs out there do, and you've cried it out in the same old simplistic fashion.
Which are exactly the qualities that you most need for performance tuning.BDKR wrote:OO just makes it easier to attain a clean, modular, easy to maintian code base.
Thanks for not letting me get away with it so easily!BDKR wrote:Cheers,
BDKR
yours, Marcus
OK. I see what you're getting at. My outlook isn't so much one of 'code-smithing' (a cool term that I'll have to remember), though I've been known to tinker and try some crazy things here and there, but instead, to do what I know performs better up front. Then, when I feel the size of the project justifies incurring the performance hit, I'll go OO.Hm...I am in the OO camp for the PHP apps I do now, but I was not out to expouse OO as such. Simply I wanted to point out that rejecting OO for performance reasons was a bad choice. There are reasons for rejecting OO, mainly when encapsulation is going to cause trouble. For example if there is a large amount of configuration or you are interfacing with a system that uses it's own language or there is very little state in the system. All of these will cause development overhead if done with OO.
But oh well...., it's all good. I'll prolly hit you up with some questions concerning C.
Cheers,
BDKR
oop not oops :)
OOP is the best way to go. Especially when php5 comes out ( since there will be major changes). See http://www.php.net/zend-engine-2.php for the new features. OOP takes a little more programming at first but once you get it to do what you want it runs like a well oiled machine...
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
One of my favorite posts on the whole procedural vs OOP thing...
http://www.sitepoint.com/forums/showpos ... stcount=14
http://www.sitepoint.com/forums/showpos ... stcount=14
Good point. I have seen code in the past using classes, just for the sake of saying they used classes. Not a valid reason.jason wrote:Writing a class and writing an Object Oriented program are two different things. Not to anyone in particular, I just want this to be clear.
The fact that you use classes in your program does NOT make your program object oriented.
Mark
-
malcolmboston
- DevNet Resident
- Posts: 1826
- Joined: Tue Nov 18, 2003 1:09 pm
- Location: Middlesbrough, UK