# [RFC] Conditional INI support - Thread: https://externals.io/message/35338 - Original archive: https://news-web.php.net/php.internals/35338 - Started by Marcus Boerger on 2008-02-09T14:33:15+00:00 - Messages: 40 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/35338.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #35338 — Marcus Boerger — 2008-02-09T14:33:15+00:00 URL: https://externals.io/message/35338#35338 Hello PHPlers, attached is a patch against 5.3 that brings three feature additions to INI parsing. 1) Ternary support for values setting = ${value?1:2} If ${value} evaluates to true then setting becomes 1 otherwise 2. This cannot be nested and only works for values, not for setting names. 2) if-elif-else-endif support [IF ${value} == 1] setting = 1 [ELIF ${value} == 2] setting = 2 [ELSE] setting = 3 [ENDIF] This can be nested. Alternatively we could use apache style syntax that looks more like XML. The reason I used square brackets is that this is the smallest change to normal INI files. 3) Add more values to INI parsing, namely: ${php.version} = 50300 ${php.debug} = 0 ${php.zts} = 0 ${php.sapi} = CLI Any comments? Best regards, Marcus --- ## #35351 — Stanislav Malyshev — 2008-02-11T05:42:33+00:00 URL: https://externals.io/message/35338#35351 · In reply to: #35338 Hi! > 1) Ternary support for values > > setting = ${value?1:2} I think it's an overkill. If you need PHP, write it in PHP. Building another programming language into the config system looks wrong to me. It's complex enough as it is. We already have the programming language, and we have ini_set, it should be enough for doing advanced stuff. > 3) Add more values to INI parsing, namely: > > ${php.version} = 50300 > ${php.debug} = 0 > ${php.zts} = 0 > ${php.sapi} = CLI What these would be used for? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #35355 — Derick Rethans — 2008-02-11T08:57:08+00:00 URL: https://externals.io/message/35338#35355 · In reply to: #35351 > > […] > > What these would be used for? The version one is atleast useful for me to load different variants of xdebug without having to edit the php.ini config file all the time. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org --- ## #35358 — Marcus Boerger — 2008-02-11T09:32:01+00:00 URL: https://externals.io/message/35338#35358 · In reply to: #35355 Hello Derick, exactly why I spent the time working on this. The ability to load the correct stuff while developing. The sapi stuff might be a better solution for sapi specific stuff as then you do not need to pass several ini files. marcus Monday, February 11, 2008, 9:57:08 AM, you wrote: > > > […] > The version one is atleast useful for me to load different variants of > xdebug without having to edit the php.ini config file all the time. > regards, > Derick > -- > Derick Rethans > http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org Best regards, Marcus --- ## #35363 — Jani Taskinen — 2008-02-11T11:06:38+00:00 URL: https://externals.io/message/35338#35363 · In reply to: #35358 > Hello Derick, > > exactly why I spent the time working on this. The ability to load the > correct stuff while developing. The sapi stuff might be a better solution > for sapi specific stuff as then you do not need to pass several ini files. > > marcus Exactly how is that different from what currently is there already: php_version = 50300 extension_dir = /some/path/${php_version}/ --Jani --- ## #35372 — Jani Taskinen — 2008-02-11T13:13:46+00:00 URL: https://externals.io/message/35338#35372 · In reply to: #35338 > 3) Add more values to INI parsing, namely: > > ${php.version} = 50300 > ${php.debug} = 0 > ${php.zts} = 0 > ${php.sapi} = CLI And btw. This also works already: php_sapi = `PHP_SAPI` Parser checks this kind of constant strings for equialent in the PHP side constants. (zend_get_constant()) ${foo} either refers to a directive set in the file prior the usage or if not set, to a ENV variable. --Jani -- Patches/Donations: http://pecl.php.net/~jani/ --- ## #35393 — Andi Gutmans — 2008-02-11T18:49:04+00:00 URL: https://externals.io/message/35338#35393 · In reply to: #35338 Hi Marcus, In general I think conditional INI support can benefit many of our users. We just need to make sure that we cover the most common needs and also that we keep it very basic and simple so that we don't boil the ocean and maintain two languages. So it's a balance we need to meet. It would be very helpful that as part of the feedback loop you write something a bit more detailed about this feature and what is and isn't supported. I imagine most people on this list would have a hard time to figure that out from the patch. This includes: - What operators are supported in conditionals - Are there any "functions" like empty() or is the ternary operator the proposed solution for that? - Is it possible to get to environment variables from this? If so how is it namespaced? How about registry on Windows? - What happens when you use a variable which is not set? - Do you propose a solution for concatenation of two values or is this outside the scope? - Can each [IF] include multiple conditionals i.e. $(value) > 1 AND $(value) < 5 or just one condition with the expectation that people will use nesting. A few specific feedbacks: - Ternary operator's syntax is a bit weird. My preference would be not to have such an operator and require using [if ..] so that it's very clear what's pre-processed even if it requires a bit more works. We don't want the INI files to become too cryptic. Also the syntax would be better formed as ${value}?1:2 but again I think it's better not to have it. - I would prefer to see [ELSEIF] instead of [ELIF] to be consistent with PHP. It would look weird for the same solution to have two approaches to this. Thanks! Andi > -----Original Message----- > From: Marcus Boerger [mailto:helly@php.net] > Sent: Saturday, February 09, 2008 6:33 AM > To: PHP Internals List > Subject: [PHP-DEV] [RFC] Conditional INI support > > Hello PHPlers, > > attached is a patch against 5.3 that brings three feature additions > to INI parsing. > > 1) Ternary support for values > > setting = ${value?1:2} > > If ${value} evaluates to true then setting becomes 1 otherwise 2. > This cannot be nested and only works for values, not for setting names. > > 2) if-elif-else-endif support > > [IF ${value} == 1] > setting = 1 > [ELIF ${value} == 2] > setting = 2 > [ELSE] > setting = 3 > [ENDIF] > > This can be nested. Alternatively we could use apache style syntax that > looks more like XML. The reason I used square brackets is that this is > the smallest change to normal INI files. > > 3) Add more values to INI parsing, namely: > > ${php.version} = 50300 > ${php.debug} = 0 > ${php.zts} = 0 > ${php.sapi} = CLI > > Any comments? > > Best regards, > Marcus --- ## #35396 — Edward Z. Yang — 2008-02-11T20:51:54+00:00 URL: https://externals.io/message/35338#35396 · In reply to: #35338 Why reinvent the wheel: just let PHP (with the `-n` flag) output, to stdout, the ini file? :o) -- Edward Z. Yang GnuPG: 0x869C48DA HTML Purifier Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] --- ## #35398 — Pierre Joye — 2008-02-11T21:31:17+00:00 URL: https://externals.io/message/35338#35398 · In reply to: #35338 Hi Marcus, Nice addition, it is really handy and it'll help to solve the php.iniS mess :) > attached is a patch against 5.3 that brings three feature > additions to INI parsing. > > 1) Ternary support for values > > setting = ${value?1:2} Sounds overkilled. Not like one will edit php.ini every day. I find the classic if elseif endif clearer. > If ${value} evaluates to true then setting becomes 1 otherwise 2. > This cannot be nested and only works for values, not for setting names. > > 2) if-elif-else-endif support > > [IF ${value} == 1] > setting = 1 > [ELIF ${value} == 2] > setting = 2 > [ELSE] > setting = 3 > [ENDIF] Perfect if ELSEIF instead of ELIF (which I can't write correctly anyway, ELSEIF comes automatically). > This can be nested. Alternatively we could use apache style syntax that > looks more like XML. The reason I used square brackets is that this is the > smallest change to normal INI files. > > 3) Add more values to INI parsing, namely: > > ${php.version} = 50300 > ${php.debug} = 0 > ${php.zts} = 0 > ${php.sapi} = CLI > > Any comments? I like it. Thanks for your work! -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #35446 — Marcus Boerger — 2008-02-13T12:35:09+00:00 URL: https://externals.io/message/35338#35446 · In reply to: #35363 Hello Jani, it is a queestion of how easy i can accomplish things. In fact I do not want to set variables in the ini file first. I want PHP to generate them for me automatically. marcus Monday, February 11, 2008, 12:06:38 PM, you wrote: > > > […] > Exactly how is that different from what currently is there already: > php_version = 50300 > extension_dir = /some/path/${php_version}/ > --Jani Best regards, Marcus --- ## #35447 — Marcus Boerger — 2008-02-13T15:45:26+00:00 URL: https://externals.io/message/35338#35447 · In reply to: #35398 Hello Pierre, Monday, February 11, 2008, 10:31:17 PM, you wrote: > Hi Marcus, > Nice addition, it is really handy and it'll help to solve the php.iniS mess :) > > > […] > Sounds overkilled. Not like one will edit php.ini every day. I find > the classic if elseif endif clearer. Yeah, and you can actually accomplish this with IF/ELSE. > > […] > Perfect if ELSEIF instead of ELIF (which I can't write correctly > anyway, ELSEIF comes automatically). Fine with me > > […] > I like it. > Thanks for your work! Best regards, Marcus --- ## #35451 — Marcus Boerger — 2008-02-13T16:26:31+00:00 URL: https://externals.io/message/35338#35451 · In reply to: #35393 Hello Andi, Pierre, Monday, February 11, 2008, 7:49:04 PM, you wrote: > Hi Marcus, > In general I think conditional INI support can benefit many of our > users. We just need to make sure that we cover the most common needs and > also that we keep it very basic and simple so that we don't boil the > ocean and maintain two languages. So it's a balance we need to meet. Right > It would be very helpful that as part of the feedback loop you write > something a bit more detailed about this feature and what is and isn't > supported. I imagine most people on this list would have a hard time to > figure that out from the patch. This includes: > - What operators are supported in conditionals <, <=, >, >=, ==, !=, &&, || all use atoi [${left} < ${right}] -> atoi(${left}) < atoi(${right}) === and !== are string comparisons [${left} === ${right}] -> !strcmp(${lect}, ${right}) Instead of === and !== I could have introduced functions like strcmp but I wanted to keep it as simple as possible for the lexer as well as the user. The only thing I might want to add is !. But that would be unary and increase complexity. > - Are there any "functions" like empty() or is the ternary operator the > proposed solution for that? None, though instead of empty() you can do: ${var}==="" > - Is it possible to get to environment variables from this? If so how is > it namespaced? How about registry on Windows? Anything the ini allows today is possible, no changes, values are evaluated just as in assignments of the ini file. > - What happens when you use a variable which is not set? > - Do you propose a solution for concatenation of two values or is this > outside the scope? afaik th eini allows that already > - Can each [IF] include multiple conditionals i.e. $(value) > 1 AND > $(value) < 5 or just one condition with the expectation that people will > use nesting. Nesting is supported as well as braces. So the following works: [(${a} < ${b}) && (${c} < ${d})] > A few specific feedbacks: > - Ternary operator's syntax is a bit weird. My preference would be not > to have such an operator and require using [if ..] so that it's very > clear what's pre-processed even if it requires a bit more works. We > don't want the INI files to become too cryptic. Also the syntax would be > better formed as ${value}?1:2 but again I think it's better not to have > it. That seems the common response her. I'll drop it. > - I would prefer to see [ELSEIF] instead of [ELIF] to be consistent with > PHP. It would look weird for the same solution to have two approaches to > this. Both of you guys say the same for the same reasons., so I changed that as well. Also I reduced the number of added values to 'php.zts' and 'php.debug'. Maybe we can add those two as consts (Pierre?). regards marcus > > […] > names. > > […] > that > > […] Best regards, Marcus --- ## #35509 — Dmitry Stogov — 2008-02-15T08:36:28+00:00 URL: https://externals.io/message/35338#35509 · In reply to: #35338 Hi Marcus, I think that the idea of ini preprocessing is great, however I would like little bit different syntax. a) I think we don't need (1) ternary support at all, as (2) if-elif=else-endif may do the same. b) I think usage of square brackets is not a good idea, because they are commonly used to divide ini files into sections. Why not to use C syntax? (#if...) c) We can use just "value" insted of ${value} in conditions. d) I would prefer not to use '.' in the variables name. It will allow to distribute conditional ini files, and use them with old PHP versions after manual preprocessing (using cpp). e) We don't need to define special names, we can use internal PHP constants. #if `PHP_VERSION` == '5.2.0' setting = 1 #elif `PHP_VERSION` == '5.3.0' setting = 2 #else setting = 3 #endif What do you think? (we can probably use similar preprocessor for PHP scripts too) Thanks. Dmitry. Marcus Boerger wrote: > Hello PHPlers, > > attached is a patch against 5.3 that brings three feature > additions to INI parsing. > > 1) Ternary support for values > > setting = ${value?1:2} > > If ${value} evaluates to true then setting becomes 1 otherwise 2. > This cannot be nested and only works for values, not for setting names. > > 2) if-elif-else-endif support > > [IF ${value} == 1] > setting = 1 > [ELIF ${value} == 2] > setting = 2 > [ELSE] > setting = 3 > [ENDIF] > > This can be nested. Alternatively we could use apache style syntax that > looks more like XML. The reason I used square brackets is that this is the > smallest change to normal INI files. > > 3) Add more values to INI parsing, namely: > > ${php.version} = 50300 > ${php.debug} = 0 > ${php.zts} = 0 > ${php.sapi} = CLI > > Any comments? > > Best regards, > Marcus > > > ------------------------------------------------------------------------ > > This body part will be downloaded on demand. --- ## #35510 — Jani Taskinen — 2008-02-15T09:30:15+00:00 URL: https://externals.io/message/35338#35510 · In reply to: #35509 > a) I think we don't need (1) ternary support at all, as (2) > if-elif=else-endif may do the same. That was already dropped. :) > b) I think usage of square brackets is not a good idea, because they are > commonly used to divide ini files into sections. Why not to use C > syntax? (#if...) I'd prefer that syntax too, it would be much clearer than mixing the sections with this. It's also backwards compatible, lines prefixed with # are simply ignored. > c) We can use just "value" insted of ${value} in conditions. Yup. ${foobar} is actually not any "variable" per se, but just a reference to existing ini entry in the file. And I don't think that needs to change. > d) I would prefer not to use '.' in the variables name. It will allow to > distribute conditional ini files, and use them with old PHP versions > after manual preprocessing (using cpp). . is acceptable since it's acceptable in ini directive names too. And works just fine in pre 5.3 versions too. > e) We don't need to define special names, we can use internal PHP constants. Yup, I mentioned this a couple of times already. :) --Jani -- Patches/Donations: http://pecl.php.net/~jani/ --- ## #35511 — Dmitry Stogov — 2008-02-15T10:02:28+00:00 URL: https://externals.io/message/35338#35511 · In reply to: #35510 Jani Taskinen wrote: > > > […] > > That was already dropped. :) > > > […] > > I'd prefer that syntax too, it would be much clearer than mixing the > sections with this. It's also backwards compatible, lines prefixed with > # are simply ignored. > > > […] > > Yup. ${foobar} is actually not any "variable" per se, but just a > reference to existing ini entry in the file. And I don't think that > needs to change. Oh, I see. Then we can use just "$string" (or "$str.str") for ini entries and "string" for PHP constants. We can also implement `defined()` macro-function, to check if constant defined. Dmitry. > > […] > > . is acceptable since it's acceptable in ini directive names too. And > works just fine in pre 5.3 versions too. > > > […] > > Yup, I mentioned this a couple of times already. :) > > --Jani --- ## #35513 — Jani Taskinen — 2008-02-15T10:17:57+00:00 URL: https://externals.io/message/35338#35513 · In reply to: #35511 > Jani Taskinen wrote: > > […] > > Oh, I see. Then we can use just "$string" (or "$str.str") for ini > entries and "string" for PHP constants. We can also implement `defined()` > macro-function, to check if constant defined. Why? Don't make php.ini parsing any more complex than it already is(n't). Any string which can pass as constant will have that constant's (or environment variable) value. Why do you need any "variable" in there anyway? And why do you need `defined()` ??? (examples please? :) --Jani -- Patches/Donations: http://pecl.php.net/~jani/ --- ## #35514 — Dmitry Stogov — 2008-02-15T10:25:42+00:00 URL: https://externals.io/message/35338#35514 · In reply to: #35513 #if defined(PHP_MAJOR_VERSION) && `PHP_MAJOR_VERSION` >= 6 extension="unicode.so" #endif Here `PHP_MAJOR_VERSION` is a PHP constant that is not defined in php-5.3 but might be defined in the future version. Dmitry. Jani Taskinen wrote: > > > […] > > Why? Don't make php.ini parsing any more complex than it already > is(n't). > > Any string which can pass as constant will have that constant's (or > environment variable) value. Why do you need any "variable" in there > anyway? And why do you need `defined()` ??? (examples please? :) > > --Jani --- ## #35515 — Marcus Boerger — 2008-02-15T11:24:14+00:00 URL: https://externals.io/message/35338#35515 · In reply to: #35514 Hello Dmitry, shouldn't this be like in C/C++ where a non existing value is treated like an empty string which behaves like false in boolean evaluations? marcus Friday, February 15, 2008, 11:25:42 AM, you wrote: > #if defined(PHP_MAJOR_VERSION) && `PHP_MAJOR_VERSION` >= 6 > extension="unicode.so" > #endif > Here `PHP_MAJOR_VERSION` is a PHP constant that is not defined in php-5.3 > but might be defined in the future version. > Dmitry. > Jani Taskinen wrote: > > […] Best regards, Marcus --- ## #35516 — Marcus Boerger — 2008-02-15T11:26:50+00:00 URL: https://externals.io/message/35338#35516 · In reply to: #35510 Hello Jani, Friday, February 15, 2008, 10:30:15 AM, you wrote: > > […] > I'd prefer that syntax too, it would be much clearer than mixing the > sections with this. It's also backwards compatible, lines prefixed with > # are simply ignored. I am fine with that if someone finds a good way to parse this. > > […] > Yup. ${foobar} is actually not any "variable" per se, but just a > reference to existing ini entry in the file. And I don't think that > needs to change. To make this clear, I did not any syntax beside the conditionals. I just used what is there. If the example I gave was misleading, then sorry for that. > > […] > Yup, I mentioned this a couple of times already. :) Right, thus I dropped all that was not needed. Best regards, Marcus --- ## #35517 — Dmitry Stogov — 2008-02-15T12:53:49+00:00 URL: https://externals.io/message/35338#35517 · In reply to: #35515 I think it will work. #ifdef UNDEFINED > 5 (false) #ifdef UNDEFINED <= 5 (true) (but anyway I think it is possible to find out an unclear condition) Dmitry. Marcus Boerger wrote: > Hello Dmitry, > > shouldn't this be like in C/C++ where a non existing value is treated like > an empty string which behaves like false in boolean evaluations? > > marcus > > Friday, February 15, 2008, 11:25:42 AM, you wrote: > > > […] > > > […] > > > […] > > > > […] > > > > > Best regards, > Marcus --- ## #35518 — Jani Taskinen — 2008-02-15T13:19:56+00:00 URL: https://externals.io/message/35338#35518 · In reply to: #35517 Currently UNDEFINED would be just string 'UNDEFINED'. Doesn't atoi() for non-numeric string make it 0 ?? (or null..:) So that would work without changing anything.. --Jani Dmitry Stogov kirjoitti: > I think it will work. > > #ifdef UNDEFINED > 5 (false) > #ifdef UNDEFINED <= 5 (true) > > (but anyway I think it is possible to find out an unclear condition) > > Dmitry. > > Marcus Boerger wrote: > > […] --- ## #35519 — Jani Taskinen — 2008-02-15T13:23:03+00:00 URL: https://externals.io/message/35338#35519 · In reply to: #35516 Marcus Boerger kirjoitti: > Hello Jani, > > Friday, February 15, 2008, 10:30:15 AM, you wrote: > > > […] > > > […] > > I am fine with that if someone finds a good way to parse this. What do you mean with 'good way' ? :) Just parse it strict like CPP does, so that any of these #if..#else..#elseif..#endif have to start from the first column in line, otherwise they're ignored.. (okay, CPP in SOME systems expects that.. :) My version of conditionals does just that. There's nothing special about it..:) Or I misunderstood what you meant with this. --Jani --- ## #35520 — Chris Stockton — 2008-02-15T13:27:23+00:00 URL: https://externals.io/message/35338#35520 · In reply to: #35517 When I think INI I think constants. What happens when I log into some server I have to debug some app instance and one of the first things I might do is check the INI and I see. [IF ${value} == 1] setting = 1 [ELIF ${value} == 2] [IF ${valuex} == 1] setting = 1 [ELIF ${valuex} == 2] settingx = ${valuexc?1: ${valuexcl?1:2}} [ELSE] [ELSE] setting = 3 [ENDIF] What is setting and settingx? Do I have to debug within the app with ini_get? Or can I dump the ini values very easily somewhere, I guess php_info() maybe?I won't deny it could be useful specially for cross-platform cross-version INI setup, but it just won't feel like a configuration file anymore is all. I almost think you should just allow PHP tags lol.. -Chris --- ## #35521 — Nathan Rixham — 2008-02-15T13:56:10+00:00 URL: https://externals.io/message/35338#35521 · In reply to: #35520 Chris Stockton wrote: > When I think INI I think constants. What happens when I log into some > server I have to debug some app instance and one of the first things I > might do is check the INI and I see. > > [IF ${value} == 1] > setting = 1 > [ELIF ${value} == 2] > [IF ${valuex} == 1] > setting = 1 > [ELIF ${valuex} == 2] > settingx = ${valuexc?1: ${valuexcl?1:2}} > [ELSE] > [ELSE] > setting = 3 > [ENDIF] > > What is setting and settingx? Do I have to debug within the app with > ini_get? Or can I dump the ini values very easily somewhere, I guess > php_info() maybe?I won't deny it could be useful specially for > cross-platform cross-version INI setup, but it just won't feel like a > configuration file anymore is all. I almost think you should just > allow PHP tags lol.. > > -Chris any chance of keeping this functionality out of the ini files either by: extended config files (like apache conf's), or changing to either an apache style conf/xml file to support if's; or indeed YAML just to jump on the YAML bandwagon, (use it as a prototype for future php yaml support?) --- ## #35522 — BuildSmart — 2008-02-15T14:33:15+00:00 URL: https://externals.io/message/35338#35522 · In reply to: #35518 Now that what-if's are occurring in the theoretical world of intelligent INI, what about file testing capabilities so that the following can be used to preload extensions by existance? #if -f ${EXTENSIONS_DIR}/gd.so extension=gd.so #endif or some other syntax that allows testing to include an extension > > Currently UNDEFINED would be just string 'UNDEFINED'. > Doesn't atoi() for non-numeric string make it 0 ?? > (or null..:) So that would work without changing anything.. > > --Jani > > Dmitry Stogov kirjoitti: > > […] > > -- > > > > -- Dale --- Next page: https://externals.io/message/35338.md?page=2