[erayd]

Originally Posted by aleyx

Just realized that AtomicDryad wouldn't see my messages to you from github...

Nah, he can see them - he's on github too, and also following the flag repo.

Do you have a specific reason to use YAML as a conf language?

Yes. JSON doesn't allow comments (which is a total pain; it's almost perfect otherwise), and INI doesn't support subsections or list of values without a named key (i.e. a numerically keyed array). YAML on the other hand supports both of those, plus it's also really nice to work with if hand-editing it.

Spyc is basically there in case the yaml extension is missing - the yaml extension is better, but depends on libyaml, and isn't bundled with PHP (it's in pear), so I figured having a fallback was a wise idea - hence that check at the beginning of flagFactory::init().

I don't really understand flagFactory. Most of it seems to deal with sources...

I think we covered that in the github discussion, but re your sources comment - that's there because it has to do with file loading and class instantiation, so flagFactory seemed like the logical place to put it. The other reason it's there is because that code needs to be run prior to config loading, and flagFactory::init() is run *very* early in the process.

I've got no problem with changing things around though - if you guys would rather do things a different way, I'm quite happy to change my approach.

...are only ever called by the config class; so maybe move them in that class?

They actually started out in the config class, but I moved them into misc because they didn't really have anything to do with config .

Actually, maybe create a flagCLI class and move everything CLI-related in it, in preparation of a flagWEB class.

I like that idea - will do.

Depending on the PHP configuration, $argc and $argv may not be available (it depends on register_argc_argv).

My understanding is that $argc and $argv are always available when using the CLI SAPI, regardless of the register_argc_argv setting. When not using CLI, we don't care about them anyway... although it would probably be a good idea to stick a php_sapi_name() call in there somewhere to figure out what kind of startup handling is required.

...as a bonus, we have less global variables.

$argc and $argv are always global, predefined by the interpreter - nothing we can do about that unfortunately.

If we can bump the PHP minimal requirement to 5.3, we can also namespace the project, and do away with all the 'flag' prefixes. That would clear up the code somewhat.

I *really* don't like that idea. While 5.3 would be very, very nice to have, it's not deployed anywhere near widely enough to count on. I'd rather not make life difficult for people trying to set this up, and a large number of distros don't even ship 5.3 yet (or at least not in an easily-obtainable way).

If we are going to go down that route though, I'd rather go the whole hog and jump to PHP 6 - but I still think that requiring anything higher than 5.2 is a bad idea.