SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 36
  1. #1
    Free your mind Toly's Avatar
    Join Date
    Sep 2001
    Location
    Panama
    Posts
    2,181
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Where do you keep your functions and classes?

    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.
    Community Guidelines | Community FAQ

    "He that is kind is free, though he is a slave;
    he that is evil is a slave, though he be a king." - St. Augustine

  2. #2
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.
    Always open to question or ridicule

  3. #3
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.
    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
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  4. #4
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    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.

    Quote Originally Posted by sweatje
    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 .

    Quote Originally Posted by sweatje
    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.
    Always open to question or ridicule

  5. #5
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  6. #6
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.)
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  7. #7
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for pulling that quote. It was probably the source of my memory, I just could not attribute it

  8. #8
    Free your mind Toly's Avatar
    Join Date
    Sep 2001
    Location
    Panama
    Posts
    2,181
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    (Peter Moulding: Blazing Site Performance Using Objects and Sessions. PHP architect, March 2003.)
    That's a nice quote. Thanks.
    Community Guidelines | Community FAQ

    "He that is kind is free, though he is a slave;
    he that is evil is a slave, though he be a king." - St. Augustine

  9. #9
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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;

    PHP Code:
    require_once "/database/mysql.php"// Load MyClass driver 
    PEAR also defines namespaces in a manner which is effective e.g.;

    PHP Code:
    // 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.

  10. #10
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    (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.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  11. #11
    SitePoint Wizard gold trophysilver trophy
    Join Date
    Nov 2000
    Location
    Switzerland
    Posts
    2,479
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  12. #12
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

    PHP Code:
    function __autoload($className) {
        @$code = $_SESSION['classes'][$className];
        if (!isset($code)) {
            $code = file_get_contents($className.'.php');
            $_SESSION['classes'][$className] = $code;
        }
        eval('?>'.$code.'<?php');
    }
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  13. #13
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't have much love for abstract classes either, kind of glad someone else shares this view ?

  14. #14
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by HarryF
    ...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.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  15. #15
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    "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

    Quote Originally Posted by HarryF
    PEAR also defines namespaces in a manner which is effective e.g.;
    Ooo... I use the same layout as PEAR.
    Always open to question or ridicule

  16. #16
    Mal Reynolds Mandibal's Avatar
    Join Date
    Aug 2003
    Location
    Columbus
    Posts
    718
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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).
    Erh

  17. #17
    Free your mind Toly's Avatar
    Join Date
    Sep 2001
    Location
    Panama
    Posts
    2,181
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.
    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?

    Quote Originally Posted by 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).
    That is a very nice article, Mandibal.

    Which of the three methods did you use for the parameter configuration?
    Community Guidelines | Community FAQ

    "He that is kind is free, though he is a slave;
    he that is evil is a slave, though he be a king." - St. Augustine

  18. #18
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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).
    I'm almost the same, I have:

    applications
    core
    data
    settings
    tmp (I just added it after reading the article )
    Always open to question or ridicule

  19. #19
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Toly
    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.
    Always open to question or ridicule

  20. #20
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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.

    PHP Code:
    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.

  21. #21
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    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.

  22. #22
    SitePoint Zealot tezza's Avatar
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sleepeasy
    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.

  23. #23
    SitePoint Zealot tezza's Avatar
    Join Date
    Aug 2003
    Location
    Australia
    Posts
    155
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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).

  24. #24
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    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.

    Quote Originally Posted by Selkirk
    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 Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  25. #25
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tezza
    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.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •