Just curious...

[Kickboy]

This is just a simple question I'm directing towards the devlopers of this Forum Software.
Sorry if this is the wrong board, but it seems fitting.

Question:
Why did you decide to design the board wihout using OOP?

Althought PHP's OOP support isn't really apparent until PHP5, it can still be usefull in PHP4.

I'm just curious, that's all.

Also, I'd like to emphasise that this forum software is probably the best I've ever seen. Kudos to the developers! 

~ Kickboy
hxxp:www.dbc-network.com [nonactive]

[Oldiesmann]

[Unknown], can you handle this one?

[[Unknown]]

Many of the benefits of OOP and even common programming practice do not apply as well for PHP.

For example, in C/C++/C#/D/other languages, I might use macro functions, inline functions, and the like to great benefit.  However, in PHP everything is compiled and run all at once, so these are not beneficial; in fact they are detrimental to most.  As such, short functions like so very often and necessarily used in OOP would significantly slow down the compilation and execution of SMF; they would be bad.

Further, as you note, many of the principles of OOP are not highly developed in PHP.  That is to say, many of the things I regard as useless (workarounds for common programming mistakes made by amatures, or those made when comments are not present, etc.) are available but those things I might want to use are not available.  Parameter hinting, for example.

Compuart, the other lead developer, dislikes many common OOP practices more than I do.  There are reasons for this, and while much of the programming community (mostly the academia) has been swooned by the ease of OOP, they have not been taught of nor often care of its downsides.

Furthermore, I can tell you that many of the methodologies in SMF have surprised people at their ease; proof that OOP is not needed to make things work well and smoothly.

That said, there is OOP used in SMF in a few places.  Where it makes sense.  XML, for example, is parsed with a class.  On the other hand, members are not - because, without much more work than would be made without a class, it would only slow down SMF to do so.

-[Unknown]

[Kickboy]

Great answer.
However, it is arguable.

In versions < PHP5, I would have to agree that OOP is... silly, at the most.  However, it is a usefull tool and if utilized properly, without resorting to the normal stupid optimization errors that are common in new PHP developers, it's efficiency impact is minimal at best. I'd also have to agree that the fact you were able to create this forum without using OOP as your API -- something rarely done on large projects -- is a great acheivment (++Kudos).

However, the benefits of OOP are apparent aswell. I mainly use classes for organizational purposes, as it keeps everything easy to work with -- so I don't have to resort to long function names in order to keep everything seperated. My biggest use for OOP is in MySQL handeling, which allows for extensive specs and debugging capabilities. (Number of queries, how long each took, etc).

Regardless, I have found this forum's code to be extremely efficient. My attempts to make it more efficient** have proved futile.

~Kickboy
hxxp:www.dbc-network.com [nonactive]

** I attempted to increase overall efficiency when I noticed that all your MySQL Queries were declared with double-quotes -- which I am sure you know are much less efficient than single-quotes. I basically converted all queries to single-quotes, and stored $db_prefix in a constant rather than a global. Unfortunetly, this proved to be uterly futile and didn't increase performance at all; infact, it slowed things down by a few microseconds.

[Midgard]

What is the OOP ?

[Kickboy]

What is the OOP ?

OOP = Object Oriented Programming

In PHP, objects are made with the 'class' language-structer.
Example:

Code Select Expand


class foo {
  function bar($par) {
     echo $par;
  }
}

$foo = new foo;
$foo->bar('test'); // Will echo 'test'


More here:
hxxp:www.php.net/oop [nonactive]

[[Unknown]]

Yes, impact can be little at best if done properly with a lot of work.  Tell me, why do I want to do this?  I get to pick between one that's faster, easier to maintain, and easier for those who don't understand OOP, and another that means more work making it efficient, means less efficient (by some) anyway...

To me, being able to create this without OOP isn't that big a deal.  A lot of people talk about scoping, and indeed that is one of the beneifts of OOP - but, think of it this way... for the code to be self documenting, long function names are better anyway.  I mean, really, what am I going to do?  I could, one, use a horrible overlord class (bad OOP anyway) like this:

$smf->removeAttachments($abc);

Which would be slower, because more code would end up in one file for that class.  Another way would be to have an "attachments" class.  Example:

$attachment_manager = new attachments_manager(); // could use autoload in PHP 5, but have to load source file in 4.
$attachment_manager->remove($abc);

Notice the lines are longer.  More typing.  In PHP 5, I might actually think this is better - the automatic file inclusion would make it cleaner (not having to global $sourcedir everywhere, maybe even have a map of which classes are in which files for cleanliness.. might be a little slower but it'd be worth it for simplicity.)  However, in PHP 4... it's just longer.  And if it WASN'T longer, it would be useless.  Example:

$att = new att();
$att->rem($abc);

I'll flog anyone who thinks that one's better.

Now, for MySQL handling.  This one I've never gotten.  Why does a class make it easier to do things like that?  Most people even use them to reduce global variables (some people then instead use an overlord class with MORE members than they would have had globals, essentially retaining EVERY bad thing about globals.)  But, tell me, how does this:

class mysql_class
{
   var $count;

   function query($string, $file, $line)
   {
      ...

      $this->count++;
   }
}
global $db;
$db = new mysql_class(...);
$db->query($abc, __FILE__, __LINE__);

Differ from this..?

function db_query($string, $file, $line)
{
   global $db_count;

   ...

   $db_count++;
}

db_query($abc, __FILE__, __LINE__);

There's the same number of globals ($db or $db_count, in this case) and the function actually has a shorter name than the class method (_ instead of ->.)

Anyway, globals don't work the same in PHP as they do C.  Polluting the global space is horrible voodoo bad in C, for good reason, but in PHP it's just another scope and doesn't push into the current scope (meaning it doesn't affect the symbol table) unless you force it to.  Using lots of globals doesn't slow down your program.  Still, it's to be avoided, because they can conflict - but if they are prefixed the same way... ($db_count/$db_prefix vs. $db->count/$db->prefix) what in the world does it matter?  Maybe a little less global'ing.

The double quotes issue is actually a bit of a thing with me.  In actuallity, there isn't that huge a difference (and by the way, constants are basically slower and unchangeable versions of global variables in PHP) and the bigger difference is with echo and using its multiple parameters.  The queries have always used double quotes, and while I've considered changing that, it's not nearly as big a deal as the templates or language files (which are a lot more in the way of strings, and used more too!)

Don't take this the wrong way.  I do agree that there are obvious benefits of OOP, some at least.  I'm just arguing that OOP was designed for compiled languages, not for scripted/interpreted ones like PHP (and you'll find that the developers of PHP actually, largely, agree with that assumption as they stated when they were asked to implement more OOP stuff in PHP 5.)  I'm also arguing that a lot of people choose to ignore the also obvious detriments of using OOP.

Now, just to make sure you understand, I actually discussed using a class for the database with Compuart, groundup, and others on the team.  It's obviously the easiest way to implement multi-database support.  It may even happen yet.  However, we came to the conclusion that, at least for SMF 1.0, the demand for non-MySQL database connection support was... minimal.  And, past that, there are horrid and annoying conflicts between the languages.  In PostgreSQL, if you select something true/false, it returns T or F, not 1 or 0 as MySQL does.  Arg.... meaning I'd have to do IF(something, 1, 0) everywhere.

Edit: as a note on what I said above, constants ARE everything that is bad about global variables in C.  They are runtime, not preprocessed like in C, so they lose all the benefits right there.  Then, they ALWAYS pollute the current scope, just like globals in C.  I avoid them when possible.

-[Unknown]

[Kickboy]

Haha.

Yes, I'd have to agree with pretty much everything you said. On a large project such as SMF that is publically released, it is probably better to do things this way. But when I make PHP scripts for my own personal use, I tend to gravitate more towards using OOP.

Now, just to make sure you understand, I actually discussed using a class for the database with Compuart, groundup, and others on the team.  It's obviously the easiest way to implement multi-database support.  It may even happen yet.  However, we came to the conclusion that, at least for SMF 1.0, the demand for non-MySQL database connection support was... minimal.  And, past that, there are horrid and annoying conflicts between the languages.  In PostgreSQL, if you select something true/false, it returns T or F, not 1 or 0 as MySQL does.  Arg.... meaning I'd have to do IF(something, 1, 0) everywhere.

Ugh. I've been to hell and back again getting PostgreSQL compatiblity. I basically said ****** it, and moved on. If you are going to do it, OOP is your friend - trust me.

~Kickboy
hxxp:www.dbc-network.com [nonactive]

[Midgard]

More here:
http://www.php.net/oop

URL doesn't work fm.

[Oldiesmann]

http://www.php.net/OOP (case-sensitive)

[Peter Duggan]

http://www.php.net/OOP (case-sensitive)

Perhaps, but the first one (http://www.php.net/oop) redirects to http://uk.php.net/oop for me and your version to http://uk2.php.net/OOP!

[Kickboy]

hxxp:www.php.net/OOP [nonactive] (case-sensitive)

Perhaps, but the first one (hxxp:www.php.net/oop [nonactive]) redirects to hxxp:uk.php.net/oop [nonactive] for me and your version to hxxp:uk2.php.net/OOP [nonactive]!

Their both the same thing. The fact that it redirects to a different server is meaningless, that's just some random occurance. For me it goes to hxxp:us3.php.net [nonactive], so it doesn't matter.

[Peter Duggan]

Their both the same thing. The fact that it redirects to a different server is meaningless, that's just some random occurance. For me it goes to us3.php.net, so it doesn't matter.

I know it doesn't matter, but the point I was making to Oldiesmann was that there was nothing wrong with your original URL.

[Compuart]

In addition to what Unknown said (he's much more of an OOP expert than me). SMF was designed with speed in mind (as well as security of course ). The part that is by far the most important thing to optimize speed is the database queries. A completely optimized database query will never fit into an OOP environment, simply because optimized queries attempt to get as much information as possible while minimizing the stress on the database as much as possible. So in order to use OOP, either you have to design (quite artificially) all objects around your database queries, or you have to add extra queries in order to be able to use OOP the way it was designed to.

In a compiled language, this will simply mean a little more overhead for loading an object, but in PHP it means both overhead and extra database stress on each click.

[Kickboy]

In addition to what Unknown said (he's much more of an OOP expert than me). SMF was designed with speed in mind (as well as security of course ). The part that is by far the most important thing to optimize speed is the database queries. A completely optimized database query will never fit into an OOP environment, simply because optimized queries attempt to get as much information as possible while minimizing the stress on the database as much as possible. So in order to use OOP, either you have to design (quite artificially) all objects around your database queries, or you have to add extra queries in order to be able to use OOP the way it was designed to.

Warning: Invalid argument detected

You wouldn't need to add or even change ANY database queries to support OOP. If you used OOP to handle your queries, the query function would just be called a little differently.

Here's how my queries are called:
$db->query('SELECT * FROM table');

Basically the only thing you'll be changing by moving to OOP is how functions are called and organized, the actual code itself will remain the same.

[Midgard]

This is great. I like em!

[Compuart]

You wouldn't need to add or even change ANY database queries to support OOP. If you used OOP to handle your queries, the query function would just be called a little differently.

Here's how my queries are called:
$db->query('SELECT * FROM table');

I'm not talking about abstraction of the database into an object. It is possible, has been investigated and found to be slower than the current method and has therefor, at least for now, been rejected.

Basically the only thing you'll be changing by moving to OOP is how functions are called and organized, the actual code itself will remain the same.

To me that sounds like a linear program using OOP now and then. True OOP will at least require to have your code organized around the most elementary objects of your script. I'd say, try to do (true) OOP without slowing down the main code flow. I don't say it's impossible, but you'll be working 90% of the time in desining OOP around the most effecient script instead of writing the best possible script.

Btw, in early stages of SMF's development, it has been done the OOP way for a short time, but we decided to abandone it, because of above mentioned reasons.

[Kickboy]

To me that sounds like a linear program using OOP now and then. True OOP will at least require to have your code organized around the most elementary objects of your script. I'd say, try to do (true) OOP without slowing down the main code flow. I don't say it's impossible, but you'll be working 90% of the time in desining OOP around the most effecient script instead of writing the best possible script.

Yeah, [Unkown] established that. I was just saying you had a flaw in your previous argument. I'm nit-picky like that.

[rjprince]

I'm not talking about abstraction of the database into an object. It is possible, has been investigated and found to be slower than the current method and has therefor, at least for now, been rejected.

Did you mean to have the "not" here? When I read your initial post on the subject, I assumed you were talking about abstracting the database structure of the application into objects, and I agreed with every word you wrote.

When kickboy responded, I assumed he was talking about merely moving the database calling code to an object, in which case he's right.

But making a $Board class, a $message class, etc. would definitely require making the DB calls less efficient.