17 years ago by Stanislav Malyshev — view source

unread

Hi!

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.

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

17 years ago by Derick Rethans — view source

unread

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

17 years ago by Marcus Boerger — view source

unread

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:

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

Best regards,
Marcus

17 years ago by Jani Taskinen — view source

unread

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

17 years ago by Marcus Boerger — view source

unread

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:

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

17 years ago by Jani Taskinen — view source

unread

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/

17 years ago by Andi Gutmans — view source

unread

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.

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.

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.

Add more values to INI parsing, namely:

${php.version} = 50300
${php.debug} = 0
${php.zts} = 0
${php.sapi} = CLI

Any comments?

Best regards,
Marcus

17 years ago by Marcus Boerger — view source

unread

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: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.

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.

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.

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,
Marcus

17 years ago by Pierre Joye — view source

unread

Hi Marcus,

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

17 years ago by Marcus Boerger — view source

unread

Hello Pierre,

cool & thx

marcus

Friday, February 15, 2008, 4:10:54 PM, you wrote:

Hi Marcus,

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

17 years ago by Edward Z. Yang — view source

unread

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 http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]

17 years ago by Pierre Joye — view source

unread

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.

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.

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.

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

17 years ago by Marcus Boerger — view source

unread

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 :)

attached is a patch against 5.3 that brings three feature
additions to INI parsing.

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.

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.

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

17 years ago by Dmitry Stogov — view source

unread

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.

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.

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.

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.

17 years ago by Jani Taskinen — view source

unread

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/

17 years ago by Dmitry Stogov — view source

unread

Jani Taskinen 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

17 years ago by Jani Taskinen — view source

unread

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/

17 years ago by Dmitry Stogov — view source

unread

#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:

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

17 years ago by Marcus Boerger — view source

unread

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:

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

17 years ago by Dmitry Stogov — view source

unread

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:

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

17 years ago by Jani Taskinen — view source

unread

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:

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

17 years ago by BuildSmart — view source

unread

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:

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:

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

--

-- Dale

17 years ago by Dmitry Stogov — view source

unread

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

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:

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

--

-- Dale

17 years ago by Jani Taskinen — view source

unread

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

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:

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

--

-- Dale

17 years ago by Chris Stockton — view source

unread

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

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

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:

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

--

-- Dale

17 years ago by Jani Taskinen — view source

unread

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

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

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:

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

--

-- Dale

17 years ago by Chris Stockton — view source

unread

Oh yaaaaa, that is why PHP isn't widely adopted in the shared hosting
world. Oh btw, I really do think we should give our users bigger guns
to shoot themselves in the foot with. We already know that if we give
them features that could be used incorrectly, they won't use them
incorrectly.

This message was configured with --sarcasm.

-Chris

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

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

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:

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

--

-- Dale

17 years ago by BuildSmart — view source

unread

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.

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
jani.taskinen@sci.fi 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

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:

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

--

-- Dale

--

--

-- Dale

17 years ago by Steph Fox — view source

unread

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" dmitry@zend.com
To: "PHP Internals List" internals@lists.php.net
Cc: jani.taskinen@iki.fi; "Marcus Boerger" helly@php.net; "Andi Gutmans"
andi@zend.com; "Jani Taskinen" jani.taskinen@sci.fi
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

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:

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

--

-- Dale

17 years ago by Marcus Boerger — view source

unread

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" dmitry@zend.com
To: "PHP Internals List" internals@lists.php.net
Cc: jani.taskinen@iki.fi; "Marcus Boerger" helly@php.net; "Andi Gutmans"
andi@zend.com; "Jani Taskinen" jani.taskinen@sci.fi
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

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:

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

--

-- Dale

--

Best regards,
Marcus

17 years ago by Steph Fox — view source

unread

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" dmitry@zend.com
To: "PHP Internals List" internals@lists.php.net
Cc: jani.taskinen@iki.fi; "Marcus Boerger" helly@php.net; "Andi
Gutmans"
andi@zend.com; "Jani Taskinen" jani.taskinen@sci.fi
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

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:

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

--

-- Dale

--

Best regards,
Marcus

17 years ago by Lukas Kahwe Smith — view source

unread

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

17 years ago by Steph Fox — view source

unread

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'.

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.

Steph

regards,
Lukas

17 years ago by Christopher Jones — view source

unread

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: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad

17 years ago by Steph Fox — view source

unread

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 ;)

17 years ago by Chris Stockton — view source

unread

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

17 years ago by Nathan Rixham — view source

unread

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?)

17 years ago by Marcus Boerger — view source

unread

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

17 years ago by Jani Taskinen — view source

unread

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