SitePoint Sponsor

User Tag List

Results 1 to 23 of 23
  1. #1
    SitePoint Enthusiast jmp($fffc)'s Avatar
    Join Date
    Nov 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    A site's config-file: constants vs. singleton/registry-patterns

    I'm experimenting with my own front controller/MVC framework, and I've been reading up on how to use a singleton to store config values for a project's website. But I'm having a hard time seeing the advantage of a singleton class to hold my config values over a simple set of defined constants.

    For my project, I'll only be using about 15 values that I need to be able to access globally. But even with a larger amount of settings I don't really see the advantage -- aside from keeping it all neatly OOP.

    Code:
    while($counter < MAX_RESULTS)
    {
    ...
    }
    ...is even nicer to read than...

    Code:
    while($counter < myconfig::get_config_value('max_results'))
    {
    ...
    }
    Or am I missing something?

  2. #2
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Or am I missing something?
    IMHO no. Some people just like to complicate things. They usually talk about scalability but you do not intend to write enterprise-wide framework, don't you?

  3. #3
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The registry pattern is more than just setting a few constant variables. It allows you to share data globally without having to define it globally.

    Global variables = BAD
    Namespaced Variables = GOOD

    Quote Originally Posted by Mastodont View Post
    Or am I missing something?
    IMHO no. Some people just like to complicate things. They usually talk about scalability but you do not intend to write enterprise-wide framework, don't you?
    Enterprise framework or not, if your writing a framework you want to be able to use it as much as possible. Having a bunch of global constants floating around decreases a frameworks re-usability and increases the risk of namespaced conflicts.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  4. #4
    SitePoint Enthusiast jmp($fffc)'s Avatar
    Join Date
    Nov 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't understand the concern with re-usability. In both cases I'd have to somehow store my settings somewhere (XML, INI file, PHP file), so you'd still end up with some kind of file which would contain all those settings. Then what's the difference between this:

    Code:
    // Maximum number of search results returned
    DEFINE('MAX_RESULTS', 50);
    // Number of columns in grid-based result view
    DEFINE('GRID_WIDTH', 4);
    and

    Code:
    // $config array which will be loaded into an object by singleton config class, as per Kohana framework example:
    
    // Maximum number of search results returned
    $config['max_results'] = 50;
    // Number of columns in grid-based result view
    $config['grid_width'] = 4;

  5. #5
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Lets so you set a constant variable in some included file atop the chain of execution.

    PHP Code:
    define('DATABASE_NAME''mydb'); 
    You have your framework running on a site and everythings just nice and dandy.. Now lets say you made this website for a client and the want you to add some logging capabilities and the client wants to be able to search and have the ability to alter the log -- deleting entries. You decide to use Sqlite to store the logs. So you create your code and define a constant for your Sqlite database file.

    PHP Code:
    define('DATABASE_NAME''logs.sqlite'); 
    And everything blows up... Ok not quite but you can see the problem.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  6. #6
    SitePoint Enthusiast jmp($fffc)'s Avatar
    Join Date
    Nov 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Imaginethis, you mean the trouble lies in the fact that with that second definition, I would overwrite the first definition for DATABASE_NAME? I see how that could be a problem, but for me this is more an example of human error that can be avoided by paying attention while editing the config file. (If indeed a singleton class would warn you that you are overwriting a previously set config variable, otherwise you have the exact same problem).

    I'm trying to learn so I'm not condemning a method, i just want to make sure I understand the pros and cons

  7. #7
    SitePoint Zealot Amenthes's Avatar
    Join Date
    Oct 2006
    Location
    Bucharest, Romania
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    The registry pattern is more than just setting a few constant variables. It allows you to share data globally without having to define it globally.

    Global variables = BAD
    Namespaced Variables = GOOD
    As long as PHP doesn't have (proper) namespaces that statement is not 100%
    true. A class name is just as global as prefixed constants.


    Quote Originally Posted by imaginethis View Post
    And everything blows up... Ok not quite but you can see the problem.
    OK, so how does Registry help in the example you gave?
    I'm under construction | http://igstan.ro/

  8. #8
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Amenthes View Post
    As long as PHP doesn't have (proper) namespaces that statement is not 100%
    true. A class name is just as global as prefixed constants.
    The global namespace and a classes namespace are still different things entirely.

    PHP Code:
    define('myconst''foo');

    class 
    blah
    {
      const 
    myconst 'bar';

    Quote Originally Posted by Amenthes View Post
    OK, so how does Registry help in the example you gave?
    The example was merely meant only to explain why global variables are bad by using an overly simple problem. The only resolution it offers is variables in the registry won't conflict with globally defined variables.
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  9. #9
    <?php while(!sleep()){code();} G.Schuster's Avatar
    Join Date
    Mar 2007
    Location
    Germany
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The advantage I see in NOT using constants is that I can change values on the fly.
    E.g. depending on the host the website is running on, a specific action the user called etc..
    You can't change defined contants, you can only use if/else-statements (or other) to change the value - that's not really nice thing.

  10. #10
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    The global namespace and a classes namespace are still different things entirely.

    PHP Code:
    define('myconst''foo');

    class 
    blah
    {
      const 
    myconst 'bar';

    PHP Code:
    define('blah_myconst''foo'); 

  11. #11
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    PHP Code:
    define('blah_myconst''foo'); 
    The global namespace and a classes namespace are still different things entirely.
    Everybody is miss understanding me today
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  12. #12
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    The example was merely meant only to explain why global variables are bad by using an overly simple problem.
    But we are talking about global constants, not variables.

  13. #13
    SitePoint Guru
    Join Date
    Jan 2005
    Location
    heaven
    Posts
    953
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A global constant is a variable...
    Creativity knows no other restraint than the
    confines of a small mind.
    - Me
    Geekly Humor
    Oh baby! Check out the design patterns on that framework!

  14. #14
    SitePoint Enthusiast jmp($fffc)'s Avatar
    Join Date
    Nov 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm trying to find the easiest way to have a config-file for a website, which will hold constants as in "changeless, unvarying in nature" data. You shouldn't be able to change "MAX_POSTS" anywhere in the application, except in the config file, but that's not really what I was asking about.

    I still think a few define-statements in my config file (or front controller for small projects) offers more oversight and the same amount of flexibilty as a singleton that stores my config settings.

  15. #15
    SitePoint Addict SirAdrian's Avatar
    Join Date
    Jul 2005
    Location
    Kelowna, BC
    Posts
    289
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I prefer to have a more structured config object.

    What if MAX_POSTS is different for different areas of your application?

    homepage.maxPosts = 50
    browsing.maxPosts 30

    ->

    $config->homepage->maxPosts

    It really does offer a lot more flexibility, and can often help explain what "maxPosts" is referring to.
    Adrian Schneider - Web Developer

  16. #16
    SitePoint Zealot Amenthes's Avatar
    Join Date
    Oct 2006
    Location
    Bucharest, Romania
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by imaginethis View Post
    The global namespace and a classes namespace are still different things entirely.
    I didn't say anything about class scope. I was referring about class names which
    are globally available, otherwise static members wouldn't be accessible in patterns
    like Registry or Singleton. kyberfabrikken already gave you a counter-example to
    yours so I'll skip that. What I want to add is that certain kind of Registries cannot
    even be compared with constants because of a very simple reason, they're mutable
    (Zend Framework for example).
    I'm under construction | http://igstan.ro/

  17. #17
    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 jmp($fffc) View Post
    I'm trying to find the easiest way to have a config-file for a website, which will hold constants as in "changeless, unvarying in nature" data. You shouldn't be able to change "MAX_POSTS" anywhere in the application, except in the config file, but that's not really what I was asking about.
    In my experience "changeless, unvarying in nature" tends to turn out to be a mirage. I often need to change my constants into variables. In this particular case, you might want to make "MAX_POSTS" configurable in some way, perhaps wanting to read the value from a database instead. You could keep the constant, making it the default value if it's not set in the database. But it would require changing the code where the constant is used. If you keep the value in a registry, for instance, you would avoid that.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  18. #18
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn View Post
    I often need to change my constants into variables.
    But not in the course of one HTTP request processing, I presume. You can save configuration array with new values before final flush and use these values as constants for new request.

  19. #19
    SitePoint Enthusiast jmp($fffc)'s Avatar
    Join Date
    Nov 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm getting nervous from people who are saying they want to change constants on the fly... why not use a variable, if you need to "change a constant"?

    I think we're nitpicking my example of "MAX_POSTS". Even when you give the user the option to show 10, 20 or 30 posts per page, you don't change a constant: you use a variable to store the numer of posts (stored in that user's session object), and you would still have to have these three options defined in your settings.

    But to get back on topic: so far, I see a singleton to store settings as overhead when buidling small to middle-sized sites. I'm building a class and using the lenghty syntax to get it to return a value to me, when I could just be using MAX_POSTS, or MY_DATABASE, or SITE_TITLE.

    (Note that I'm talking about settings crucial to running the website, not about database-stored settings that must be editable through some kind of admin panel -- that's a different kind of settings in this case.)

  20. #20
    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 Mastodont View Post
    But not in the course of one HTTP request processing, I presume. You can save configuration array with new values before final flush and use these values as constants for new request.
    You're saying generate the code to set the constants?? Or just save and regenerate variables with values that were originally set as constants? Maybe I just don't get it. If you use variables anyway, what exactly is the point of using constants?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  21. #21
    SitePoint Addict Mastodont's Avatar
    Join Date
    Mar 2007
    Location
    Czech Republic
    Posts
    375
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    what exactly is the point of using constants
    They are immutable and have global scope.

  22. #22
    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 Mastodont View Post
    what exactly is the point of using constants
    They are immutable and have global scope.
    I know that. You answered just the easy part of the question. My question was, if you stuff the data into variables anyway (assuming that's what you're suggesting), what are the constants for?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  23. #23
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jmp($fffc) View Post
    But to get back on topic: so far, I see a singleton to store settings as overhead when buidling small to middle-sized sites. I'm building a class and using the lenghty syntax to get it to return a value to me, when I could just be using MAX_POSTS, or MY_DATABASE, or SITE_TITLE.
    the only difference between an singleton and constants are that singleton
    properties are runtime mutable. leaves the fact that both are globally
    accessible and that is the heart of the problem. if you can live with this
    problem use what you want.

    personally i use constants only for real constant values that will never
    change. that may be constants for cardinal points or the size of an octet.
    anything that may change like platform, server or application dependend
    values are stored in a plain configuration container (array) and only values
    needed by an object are passed to it. this makes life simple because
    it's very unlikely that any structural changes are needed.


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
  •