I suppose using a PHP keyword like include may lead to a desire for other PHP keywords, perhaps something like:
additional_ini = /some/dir additional_ini = /some/file.ini Not sure why you want to limit it to one. Also, they can be nested, so in /some/dir/foo.ini you might have: additional_ini = /some/dir/my_ext My only concern about the full directory scanning and reading every file is that there could be foo.ini~ created by editors or other such junk in there. So perhaps only read in .ini files, or maybe use the new glob code to allow /some/dir/*.ini to specify. Probably going a bit too far as well. -Rasmus On Thu, 26 Sep 2002, Zeev Suraski wrote: > I'm concerned that adding this directive will make lead to control > structures requirements. However, it is quite useful for modular > deployment; So, my suggestion is: > > - Don't introduce 'include' > - Introduce a special 'additional_ini_directory' (name subject to change) > which will be read after php.ini loads up. Only one (at most) such > directory, full path required. > > This gives you (as far as I can tell) the modular deployment features, but > won't make people beg for 'if'. > > Thoughts? > > Zeev > > At 00:50 26/09/2002, Rasmus Lerdorf wrote: > >I don't see any obvious problems with this patch except for a couple of > >extrananeos changes. I was a bit indisposed last week and didn't really > >follow the discussion leading up to this, but I have read the archive. I > >agree that going full out with PHP-parsed .ini files is going too far, but > >being able to do a simple include of individual files or directories of > >files seems like a useful thing to me when building a modular PHP > >deployment system. > > > >-Rasmus > > > > > >-- > >PHP Development Mailing List <http://www.php.net/> > >To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
