Hacker News Reader

Comment by dools | Hacker News Reader

I actually like having config files as PHP - that way you can not only include comments but hack in logic if you ever have to.

View on HN

PHP config files are much like PHP templates. It sounds handy to be able to do the odd quick hack in there, but on large scale project it always ends up as a gigantic mess in my experience. Quick hack over quick hack, it slowly turns into an unreadable maze of possibilities.

That being said, for packages I really don't think this applies, because it's static declarative information, I can't imagine why you would need "quick hacks" adding logic to that.

We used to do that with Midgard. Just like embedding in logic into your templates, it gives you a lot of flexibility but ultimately ends up with you or your users shooting yourself into the foot.

For reference, here is one of the old, PHP-based config files we have: http://trac.midgard-project.org/browser/branches/ragnaroek/m...

Using homogeneous architecture has tremendous advantages over using a patchwork of different formats and languages.

Quick example. If you're using native PHP templates and configs, installing APC gives you instant template and config caching with zero effort. To get the same functionality for other formats you would need to roll our your own caching, introducing bugs and complexity along the way, but, most importantly, reinventing the wheel.

That's just one out of myriad examples.

Also, if you have more than two nested levels of arrays (regardless of the language used) in a giant uber-config file, you are the one who is shooting your users into their feet.

Don't code XML in PHP. Refactor. Use includes (which JSON doesn't have, BTW). Use autoconfig pattern and align your configuration file with classes that use them. Use sensible conventions over configuration. Start the file with return statement instead of magic name:

  <?php
   return array(
     'var' => "val",
   );

Nothing will ever scale if you don't even try to design it in a sensible way.

I didn't know that you could return a value from an include like that, that's incredibly handy (and makes me wonder why almost nobody does it that way).

I love this strategy, it's great for config. For example in the RocketSled microframework I mentioned earlier[1] you have a config file to instruct the system which class to execute by default in which you just put:

<?php return 'Hello World';

Being able to include a file like that in your project which returns a value has the advantage (in my opinion anyway) of not cluttering up the namespace with lots of defines(), of not requiring any magic naming convention, and of not having to call out to any external functions or edit config files that are part of the core system's version control.

[1]https://github.com/iaindooley/RocketSled

Admittedly, the example above is quite convoluted. Most of the config files looked like this, which is almost what JSON could look like if it was based on PHP syntax instead of JavaScript:

http://trac.midgard-project.org/browser/branches/ragnaroek/m...

Compared to other formats, it looks like it's missing braces at the top and bottom of the file. YAML gets around it by not requiring trailing commas and not reminding people too much of another format.

Jesus you expected a human to produce that file??? No wonder they shot themselves in the foot! My solution to that wouldn't be a different config format, but less config.

There are advantages and disadvantages. I recently moved to JSON config files for my projects, because they are easy to update from inside the app and because they can be easily validated.

Reply on news.ycombinator.com