Where do you keep your functions and classes?

[Toly]

Do you put all functions and classes in one file and then include that file at the top of each page? Do you use one file for functions and another one for classes? Do you put non-related classes in different files?

Just curious to know.

[sleepeasy]

I always keep classes seperate ie one file = one class.

I always group related functions to one file, and keep the number of functions in each file under a reasonable number.

I had to give up helping out on an Open Source application some months ago because I couldn't stand the fact that they insisted on keeping every function in one huge file - I'm talking several megabytes here! (not to mention the fact that they always double-quoted strings even if they contained no variables even after I explained why this was A Bad Thing).

In my opinion, the main problem with keeping hundreds of functions in one file is that it gives the PHP parser more work to do - The more functions you have in a file the less likely it is that you will use every function in that file each time it's include()'d. Any function that isn't used is unneeded work for the parser.

[sweatje]

I always keep classes seperate ie one file = one class.

I always group related functions to one file, and keep the number of functions in each file under a reasonable number.

I had to give up helping out on an Open Source application some months ago because I couldn't stand the fact that they insisted on keeping every function in one huge file - I'm talking several megabytes here! (not to mention the fact that they always double-quoted strings even if they contained no variables even after I explained why this was A Bad Thing).

In my opinion, the main problem with keeping hundreds of functions in one file is that it gives the PHP parser more work to do - The more functions you have in a file the less likely it is that you will use every function in that file each time it's include()'d. Any function that isn't used is unneeded work for the parser.

There is somewhat of a performance argument that without php accelleration, a single file may parse faster than many separate files (optimizing for speed rather than memory consumption, because each apache process typically allocates enought to hold all the parsed classes anyway, and the system IO time to locate each of the separate files is > the time require to parse additional non-required (for this request) classes in the giant file). HOWEVER...seeing as they ignored your advice on the quoting, it does not sound like their rational for the single file was optimization based.

I had an idea one time that if it really were that critical to me, (and for some reason I could not install a php byte cache) then I would make a build system that would aggregate all of my individual files into a single include file for the production system, but I would continue to maintain the source in separate files for usability.

HTH

[sleepeasy]

There is somewhat of a performance argument that without php accelleration, a single file may parse faster than many separate files (optimizing for speed rather than memory consumption, because each apache process typically allocates enought to hold all the parsed classes anyway, and the system IO time to locate each of the separate files is > the time require to parse additional non-required (for this request) classes in the giant file).

I haven't heard this argument before. It seems feasible enough although, correct me if I'm wrong, I would suggest that the number of IO operations would have to be quite large before becoming an performace issue.

HOWEVER...seeing as they ignored your advice on the quoting, it does not sound like their rational for the single file was optimization based.

It wasn't. It was mainly so they would only have write one include statement. I think they listed "All functions are in one file" as one of the pro's of their application on it's website.

They also used cryptic method and variable names - but I won't bore you with all that .

I had an idea one time that if it really were that critical to me, (and for some reason I could not install a php byte cache) then I would make a build system that would aggregate all of my individual files into a single include file for the production system, but I would continue to maintain the source in separate files for usability.
HTH

Interesting idea.

And you mentioned another advantage of using seperate files that I left out of my previous post: usability or maintainablilty.

[Widow Maker]

I only every have the one file - usually named utilities.php - which holds the non OOP functions I need for a given project, and nothing more.

A case of Copy and Paste of what is needed or used, keeping the filesize down as much as possible, and being only the one INCLUDE

But that Open Source project you talked about lookes seriously dodge to me And a comment such as you've pointed out plastered all other the front page just goes to show how much these people mis understand the use and capability of PHP IMO as well...

Firing squad at dawn

[dagfinn]

Files are the curse of object-oriented programming...If you take 20 classes, place them in separate files, then run a script requiring all 20 classes, your script will run like a dog with a broken leg. Try the same script including 100 classes, and no matter how small the classes, the script will run like a dog with 3 legs broken. Now copy all the classes into one big include file and test again. Pow! you are back to the speed of light. Each file open costs you several times more overhead than each read.

(Peter Moulding: Blazing Site Performance Using Objects and Sessions. PHP architect, March 2003.)

[sweatje]

Thanks for pulling that quote. It was probably the source of my memory, I just could not attribute it

[Toly]

(Peter Moulding: Blazing Site Performance Using Objects and Sessions. PHP architect, March 2003.)

That's a nice quote. Thanks.

[HarryF]

The other angle though, on keeping classes in seperate files, is it allows you to include them on demand. Was going on about this in Lazy PHP. It's a balancing act, for which XDebug is very handy.

As to locations, an effective approach is that used by PEAR. Fix a single directory in your include path and place you classes in directories relative to that e.g.;

/home/username/phplib/ << add to php include path
/home/username/phplib/database/ << database classes

Then in your code;

require_once "/database/mysql.php"; // Load MyClass driver 

PEAR also defines namespaces in a manner which is effective e.g.;

// Full path: /home/username/pear/Calendar/Month.php
require_once 'Calendar/Month.php';

// Notice prefix Calendar_
$Month = new Calendar_Month(2004,2);

// Full path: /home/username/pear/Calendar/Month/Weekdays.php
require_once 'Calendar/Month/Weekdays.php';

$MonthW = new Calendar_Month_Weekdays(2004,2); 

See how there's a base namespace Calendar_ and further namespaces follow the directory structure, like Calendar_Month_, while the file names themselves correspond to the final part of the classname.

[dagfinn]

(Written before HarryF's reply: ) I do feel that this is a dilemma, though. I like to have one file per class. Not require()-ing the file until it's needed is a possibility that looms larger with __autoload() in PHP 5. If you have 20 classes that all depend on each other (somewhat extreme, perhaps...?), you still have the problem, but less of it. If you have 100 class files, you will never have to open all of them for each HTTP request.

[HarryF]

If you have 20 classes that all depend on each other (somewhat extreme, perhaps...?)

Found I've been influenced alot by Jeff (selkirk) + WACT recently. In particular, regarding abstract classes (which is where that 20+ can come from), either as convention in PHP or declared in PHP5, use them only when you really must, in PHP. If code has no purpose other than to instruct other developers, don't bother. As PHP source code is generally always available, use well placed comments instead. And the more I think about interfaces, in PHP5, the more I think they're an expensive luxury.

WACT is already reaching fairly significant complexity and has four developers collaborating over the wire. Generally there's little confusion and I can't think of an example where a dumb abstract class would have helped, where there was.

[dagfinn]

This example has some imperfections, notably the fact that it doesn't use the include path, and I haven't tested it. But what I've tried to do is use Moulding's idea of storing the class code in the session and make a PHP 5 autoload function that will get the class from a file only if it hasn't been used before during the session.

function __autoload($className) {
    @$code = $_SESSION['classes'][$className];
    if (!isset($code)) {
        $code = file_get_contents($className.'.php');
        $_SESSION['classes'][$className] = $code;
    }
    eval('?>'.$code.'<?php');
}

[Widow Maker]

I don't have much love for abstract classes either, kind of glad someone else shares this view ?

[dagfinn]

...dumb abstract...

"Dumb abstract class" would be the technical term for a class that has only abstract methods, I suppose. If a class has some real code, but is incomplete so there's no point in instantiating it, that's different.

But I could easily call some of the new PHP 5 features pretentious nonsense if I'm in a bad enough mood. That would include abstract classes, interfaces, and private and protected methods, They're marginally helpful at best. I only want to use them if they're not causing problems.

[sleepeasy]

"Dumb abstract class" would be the technical term for a class that has only abstract methods, I suppose. If a class has some real code, but is incomplete so there's no point in instantiating it, that's different.

But I could easily call some of the new PHP 5 features pretentious nonsense if I'm in a bad enough mood. That would include abstract classes, interfaces, and private and protected methods, They're marginally helpful at best. I only want to use them if they're not causing problems.

I must be the only one here who's glad of the new stuff in PHP5

PEAR also defines namespaces in a manner which is effective e.g.;

Ooo... I use the same layout as PEAR.

[Mandibal]

I use the method outlined in this article. For all of my reusable code. Then I use a lib dir in my web sites dir for all the site specific classes (presentation layer stuff, domain layer stuff and data layer).

[Toly]

The other angle though, on keeping classes in seperate files, is it allows you to include them on demand. Was going on about this in Lazy PHP. It's a balancing act, for which XDebug is very handy.

You make a good point in that PHP blog. I've always tried to avoid unecessary executions, like select all queries if there are cero rows and stuff like that.

Despite the quote degfinn provided, it could get messy to have, say 50 classes in one file. If at some point you'd like to change something on one class, you'd have to go through all the 50 classes until you find the right one, assuming you don't find it right away.

Am I right to assume that keeping non-related classes in different files to include them as needed would be the best approach?

I use the method outlined in this article. For all of my reusable code. Then I use a lib dir in my web sites dir for all the site specific classes (presentation layer stuff, domain layer stuff and data layer).

That is a very nice article, Mandibal.

Which of the three methods did you use for the parameter configuration?

[sleepeasy]

I use the method outlined in this article. For all of my reusable code. Then I use a lib dir in my web sites dir for all the site specific classes (presentation layer stuff, domain layer stuff and data layer).

I'm almost the same, I have:

applications
core
data
settings
tmp (I just added it after reading the article )

[sleepeasy]

Despite the quote degfinn provided, it could get messy to have, say 50 classes in one file. If at some point you'd like to change something on one class, you'd have to go through all the 50 classes until you find the right one, assuming you don't find it right away.

Especially difficult considering the scrollbar would probably be smaller than your mouse pointer.

[Selkirk]

This example has some imperfections, notably the fact that it doesn't use the include path, and I haven't tested it. But what I've tried to do is use Moulding's idea of storing the class code in the session and make a PHP 5 autoload function that will get the class from a file only if it hasn't been used before during the session.

function __autoload($className) {
    @$code = $_SESSION['classes'][$className];
    if (!isset($code)) {
        $code = file_get_contents($className.'.php');
        $_SESSION['classes'][$className] = $code;
    }
    eval('?>'.$code.'<?php');
}

Sessions aren't magic. Why would loading code from a file based session and doing an eval on it be faster than loading it from a plain old source code file with require? Why would loading the code with file_get_contents() and doing an eval on it be any faster than requiring it or any different than loading it from a file based session? A database based session would plague you with concurrency issues and harm the scalability of your app. Also, I doubt that the opcode caches much like eval. I bet plain old require and include are fastest in all situations.

[Selkirk]

I had an idea one time that if it really were that critical to me, (and for some reason I could not install a php byte cache) then I would make a build system that would aggregate all of my individual files into a single include file for the production system, but I would continue to maintain the source in separate files for usability.

I think Mojavi does this for its core classes, strips the comments too. I have some interesting benchmarks for this. I'll try and find them.

[tezza]

I must be the only one here who's glad of the new stuff in PHP5

Me too. I think there's no point commenting on the usefulness of a feature when that comment is purely based on whether the commenter sees an immediate need for themselves to use it 8)

For instance, if you are developing a framework or library for other developers to use, then the usefulness of abstract classes and interfaces is obvious -- there is nothing pretentious about it**. If however, a developer is not "specifying" requirements to work with said library/framework, then they will probably never use abstract classes/interfaces. In which case, making their comment on the usefulness broad and encompasing would be, well, useless

It's horses for courses. and php5 now does more courses (as eveloution would have it). I for one will take it on some of those new courses. But my usage of it does not define it's usefulness.


** These features allow you to plug in and out different engines which do the same job but which might be supplied by different vendors (with different licences) or have different features or efficiencies. A critical aspect of application scalability. Case in point, I can get my application to use javax calls to implement my XSLT stylesheets. I can also switch XSLT processors without touching my app. It's like hot swapping -- no re-code required.

[tezza]

as for where to include stufff...

I think what Harry says makes the most sense. The PEAR approach works well and is most suitable for those looking for a guide.

I'll also make the comment about "dangling" functions that are not part of any class. It doesn't hurt to group your functions by class so that you don't have a bunch of global functions floating around on top of the built-in PHP ones. You could for example make a class called "UTILS" and then access all the function there statically. so...

UTILS::$strMyFunctionName($arrArgs);

when you read the code, it is obvious which functions are yours and which are built-in PHP functions.

You can then use the 1 class per file approach to further organise your code.

If some of your groups/classes are ebstract enough, you can re-use them in other apps (or even extend them to customise them for that app).

[dagfinn]

Sessions aren't magic. Why would loading code from a file based session and doing an eval on it be faster than loading it from a plain old source code file with require?

It wouldn't if it's just one file in either case. My example implies that the code is in any number of files, one per class. The session file is just one file. Adding additional variables to the session will increase the time taken to load the session only if additional file blocks are needed, and an additional block is faster than opening an additional file.

All of this is detailed in Moulding's article.

Why would loading the code with file_get_contents() and doing an eval on it be any faster than requiring it or any different than loading it from a file based session? A database based session would plague you with concurrency issues and harm the scalability of your app. Also, I doubt that the opcode caches much like eval. I bet plain old require and include are fastest in all situations.

I'm not trying to pretend I know everything. I'm just suggesting a possible solution The only way to be sure which one is best is to measure the different alternatives. To the extent that I have so far, my experience seems to bear out the considerations presented by Moulding in the PHP architect article.

[dagfinn]

These features allow you to plug in and out different engines which do the same job but which might be supplied by different vendors (with different licences) or have different features or efficiencies. A critical aspect of application scalability. Case in point, I can get my application to use javax calls to implement my XSLT stylesheets. I can also switch XSLT processors without touching my app. It's like hot swapping -- no re-code required.

I don't think there's any question that it's useful to put identical interfaces on components that do the same thing. But this will work in PHP without using the Interface language construct. Unless, that is, you're actively using type hints or other forms of type checking.

Constructs such as Interface do serve a purpose as documentation. Although that is somewhat useful, I'm not sure it's worth it if you have to pay a performance penalty.