Re: [PHP-DEV] [RFC] Conditional INI support
On 16.02.2008, at 11:05, Marcus Boerger wrote: Hello Steph, so here's my take on the matters. For 5.4 we collect ideas and implement them. So that 5.4 comes out with mostly PECL. I guess we can collect action items on Lukas' wiki. Well maybe we should target this stuff for PHP6 for the time being. A possible PHP 5.4 would then be a collection of PHP6 todo items that we want to fast track, or are you guys already certain about PHP 5.4? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Hi Chris, I'd like to see pecl4win merged into pecl.php.net (adding to Steph's idea of releasing binaries on pecl.php.net), and the Windows binaries being built from their correct branch (whatever happened to this project - it seemed so close?) What happened to this idea is there's no consensus about 'the correct branch', or about the need for tagging. Several (most?) PECL packages are developed to be completely independent of the PHP release cycle; the same code will build against all current PHP versions. I think if we keep the PECL release binaries for the current stable PHP(s) on pecl.php.net and keep the development-related stuff in CVS and on the snaps boxes, it'll make life much less confusing. PECL release binaries are only tied to a branch of PHP by the version of PHP they were built against. - Steph PS Lukas, it's okay, I killed his signature ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Steph Fox wrote: Hi Lukas, Well maybe we should target this stuff for PHP6 for the time being. A possible PHP 5.4 would then be a collection of PHP6 todo items that we want to fast track, or are you guys already certain about PHP 5.4? I'm thinking 'get the mechanisms into place in 5.4, move stuff out of core in 6.0'. This sounds practical. No idea if that makes sense to everyone, but to move out of core or not isn't even an option without a good way to distribute PECL. I'd like to see pecl4win merged into pecl.php.net (adding to Steph's idea of releasing binaries on pecl.php.net), and the Windows binaries being built from their correct branch (whatever happened to this project - it seemed so close?) Chris PS Lukas, sorry for the three line signature. -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Hello Steph,
so here's my take on the matters. For 5.4 we collect ideas and implement
them. So that 5.4 comes out with mostly PECL. I guess we can collect action
items on Lukas' wiki.
marcus
Saturday, February 16, 2008, 2:05:06 AM, you wrote:
I'm with Dmitry - but syntax aside, the only way this becomes even halfway
important is if the whole PECL scenario is sorted out in a way that makes
good sense to the end users.
Back to square one. Sorry guys but sooner or later this has to be dealt
with. We need to be sure of what a PHP installation is likely to mean... to
everybody.
- Steph
- Original Message -
From: Dmitry Stogov [EMAIL PROTECTED]
To: PHP Internals List internals@lists.php.net
Cc: [EMAIL PROTECTED]; Marcus Boerger [EMAIL PROTECTED]; Andi Gutmans
[EMAIL PROTECTED]; Jani Taskinen [EMAIL PROTECTED]
Sent: Friday, February 15, 2008 2:38 PM
Subject: Re: [PHP-DEV] [RFC] Conditional INI support
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
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
On Feb 15, 2008, at 8:19 AM, Jani Taskinen wrote:
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:
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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Hi Marcus,
so here's my take on the matters. For 5.4 we collect ideas and implement
them. So that 5.4 comes out with mostly PECL. I guess we can collect
action
items on Lukas' wiki.
Greg tells me he's been working so hard on ext/phar lately that Pyrus is
still pre-alpha - it's not going to be ready in time for 5.3. So your
approach sounds good to me...
Lukas?
- Steph
marcus
Saturday, February 16, 2008, 2:05:06 AM, you wrote:
I'm with Dmitry - but syntax aside, the only way this becomes even
halfway
important is if the whole PECL scenario is sorted out in a way that makes
good sense to the end users.
Back to square one. Sorry guys but sooner or later this has to be dealt
with. We need to be sure of what a PHP installation is likely to mean...
to
everybody.
- Steph
- Original Message -
From: Dmitry Stogov [EMAIL PROTECTED]
To: PHP Internals List internals@lists.php.net
Cc: [EMAIL PROTECTED]; Marcus Boerger [EMAIL PROTECTED]; Andi
Gutmans
[EMAIL PROTECTED]; Jani Taskinen [EMAIL PROTECTED]
Sent: Friday, February 15, 2008 2:38 PM
Subject: Re: [PHP-DEV] [RFC] Conditional INI support
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
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
On Feb 15, 2008, at 8:19 AM, Jani Taskinen wrote:
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:
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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
On Fri, 2008-02-15 at 11:36 +0300, Dmitry Stogov wrote:
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Jani Taskinen wrote:
On Fri, 2008-02-15 at 11:36 +0300, Dmitry Stogov wrote:
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.
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
#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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Hello Jani,
Friday, February 15, 2008, 10:30:15 AM, you wrote:
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.
I am fine with that if someone finds a good way to parse this.
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.
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.
e) We don't need to define special names, we can use internal PHP constants.
Yup, I mentioned this a couple of times already. :)
Right, thus I dropped all that was not needed.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
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:
#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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Marcus Boerger kirjoitti: Hello Jani, Friday, February 15, 2008, 10:30:15 AM, you wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
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?)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Dmitry, please don't throw gasoline on the flames.
We have to keep the ini files as simple as possible, this isn't the job of
the ini file.
--Jani
Dmitry Stogov kirjoitti:
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
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
On Feb 15, 2008, at 8:19 AM, Jani Taskinen wrote:
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:
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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Hi Marcus, On Wed, Feb 13, 2008 at 5:26 PM, Marcus Boerger [EMAIL PROTECTED] wrote: Also I reduced the number of added values to 'php.zts' and 'php.debug'. Maybe we can add those two as consts (Pierre?). Done, both PHP_DEBUG (same as ZEND_DEBUG) and PHP_ZTS, in 5.3 and HEAD. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
The if-else is very basic thing. And it's quite necessary to make the
user.ini stuff useful. Especially for hosting companies.
If someone abuses it, they're pretty much on their own anyway.
--Jani
Chris Stockton kirjoitti:
It might be to late to keep it simple, once you add basic language
components like IF-ELSE as you can see people already want basically
another programming language embedded into it. It is my opinion that
the INI files should be simple configuration files. Otherwise they
will become more and more feature rich and people will start shifting
program complexity from the PHP application to the INI file. This
might not be the intention of the people in this list as you are all
pretty sharp, but have you read some of the online tutorials on php? I
just think this kind of feature would be badly abused...
-Chris
On Fri, Feb 15, 2008 at 7:40 AM, Jani Taskinen [EMAIL PROTECTED] wrote:
Dmitry, please don't throw gasoline on the flames.
We have to keep the ini files as simple as possible, this isn't the job of
the ini file.
--Jani
Dmitry Stogov kirjoitti:
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
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
On Feb 15, 2008, at 8:19 AM, Jani Taskinen wrote:
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:
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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
It might be to late to keep it simple, once you add basic language
components like IF-ELSE as you can see people already want basically
another programming language embedded into it. It is my opinion that
the INI files should be simple configuration files. Otherwise they
will become more and more feature rich and people will start shifting
program complexity from the PHP application to the INI file. This
might not be the intention of the people in this list as you are all
pretty sharp, but have you read some of the online tutorials on php? I
just think this kind of feature would be badly abused...
-Chris
On Fri, Feb 15, 2008 at 7:40 AM, Jani Taskinen [EMAIL PROTECTED] wrote:
Dmitry, please don't throw gasoline on the flames.
We have to keep the ini files as simple as possible, this isn't the job of
the ini file.
--Jani
Dmitry Stogov kirjoitti:
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
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
On Feb 15, 2008, at 8:19 AM, Jani Taskinen wrote:
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:
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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
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
On Feb 15, 2008, at 8:19 AM, Jani Taskinen wrote:
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:
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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Take a look at apache's config mechanism, it allows conditional
arguments.
Yes, it can be abused but we're not talking about an extensive INI
language, just something covering basic conditional control.
On Feb 15, 2008, at 9:48 AM, Chris Stockton wrote:
It might be to late to keep it simple, once you add basic language
components like IF-ELSE as you can see people already want basically
another programming language embedded into it. It is my opinion that
the INI files should be simple configuration files. Otherwise they
will become more and more feature rich and people will start shifting
program complexity from the PHP application to the INI file. This
might not be the intention of the people in this list as you are all
pretty sharp, but have you read some of the online tutorials on php? I
just think this kind of feature would be badly abused...
-Chris
On Fri, Feb 15, 2008 at 7:40 AM, Jani Taskinen
[EMAIL PROTECTED] wrote:
Dmitry, please don't throw gasoline on the flames.
We have to keep the ini files as simple as possible, this isn't
the job of
the ini file.
--Jani
Dmitry Stogov kirjoitti:
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
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
On Feb 15, 2008, at 8:19 AM, Jani Taskinen wrote:
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:
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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
PGP.sig
Description: This is a digitally signed message part
Re: [PHP-DEV] [RFC] Conditional INI support
Hello Pierre, cool thx marcus Friday, February 15, 2008, 4:10:54 PM, you wrote: Hi Marcus, On Wed, Feb 13, 2008 at 5:26 PM, Marcus Boerger [EMAIL PROTECTED] wrote: Also I reduced the number of added values to 'php.zts' and 'php.debug'. Maybe we can add those two as consts (Pierre?). Done, both PHP_DEBUG (same as ZEND_DEBUG) and PHP_ZTS, in 5.3 and HEAD. -- Pierre http://blog.thepimp.net | http://www.libgd.org Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
I'm with Dmitry - but syntax aside, the only way this becomes even halfway
important is if the whole PECL scenario is sorted out in a way that makes
good sense to the end users.
Back to square one. Sorry guys but sooner or later this has to be dealt
with. We need to be sure of what a PHP installation is likely to mean... to
everybody.
- Steph
- Original Message -
From: Dmitry Stogov [EMAIL PROTECTED]
To: PHP Internals List internals@lists.php.net
Cc: [EMAIL PROTECTED]; Marcus Boerger [EMAIL PROTECTED]; Andi Gutmans
[EMAIL PROTECTED]; Jani Taskinen [EMAIL PROTECTED]
Sent: Friday, February 15, 2008 2:38 PM
Subject: Re: [PHP-DEV] [RFC] Conditional INI support
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
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
On Feb 15, 2008, at 8:19 AM, Jani Taskinen wrote:
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:
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:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
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.
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
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:
On Mon, 2008-02-11 at 10:32 +0100, Marcus Boerger wrote:
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
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
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 :)
On Feb 9, 2008 3:33 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
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.
Yeah, and you can actually accomplish this with IF/ELSE.
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).
Fine with me
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!
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
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
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
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
Best regards,
MarcusIndex: main/php_ini.c
===
RCS file: /repository/php-src/main/php_ini.c,v
retrieving revision 1.136.2.4.2.15.2.7
diff -u -p -d -r1.136.2.4.2.15.2.7 php_ini.c
--- main/php_ini.c 3 Feb 2008 14:35:59 - 1.136.2.4.2.15.2.7
+++ main/php_ini.c 13 Feb 2008 16:20:26 -
@@ -20,6 +20,7 @@
#include php.h
#include ext/standard/info.h
+#include ext/standard/basic_functions.h
#include zend_ini.h
#include zend_ini_scanner.h
#include php_ini.h
@@ -328,6 +329,32 @@ static void php_load_zend_extension_cb(v
}
/* }}} */
+PHPAPI void php_ini_add_config_stringl(const char* name, int name_size, const
char *value, int value_len TSRMLS_DC) /* {{{*/
+{
+ zval tmp;
+ ZVAL_STRINGL(tmp, zend_strndup(value, value_len), value_len, 0);
+ Z_SET_REFCOUNT(tmp, 0);
+ Z_UNSET_ISREF(tmp);
+ zend_hash_update(configuration_hash, name, name_size, (void *) tmp,
sizeof(zval), NULL);
+} /* }}} */
+
+PHPAPI void php_ini_add_config_string(const char* name, int name_size, const
char *value TSRMLS_DC) /* {{{*/
+{
+ php_ini_add_config_stringl(name, name_size, value, strlen(value)
TSRMLS_CC);
+} /* }}} */
+
+PHPAPI
RE: [PHP-DEV] [RFC] Conditional INI support
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:[EMAIL PROTECTED]
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
On Sat, 2008-02-09 at 15:33 +0100, Marcus Boerger wrote:
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
On Sun, 10 Feb 2008, Stanislav Malyshev wrote:
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?
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
On Mon, 2008-02-11 at 10:32 +0100, Marcus Boerger wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
