Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35535 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5939 invoked by uid 1010); 15 Feb 2008 20:37:10 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 5924 invoked from network); 15 Feb 2008 20:37:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Feb 2008 20:37:10 -0000 Authentication-Results: pb1.pair.com header.from=buildsmart@daleenterprise.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=buildsmart@daleenterprise.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain daleenterprise.com from 67.78.11.229 cause and error) X-PHP-List-Original-Sender: buildsmart@daleenterprise.com X-Host-Fingerprint: 67.78.11.229 daleenterprise.com Received: from [67.78.11.229] ([67.78.11.229:53586] helo=daleenterprise.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FF/5D-11466-4F7F5B74 for ; Fri, 15 Feb 2008 15:37:09 -0500 Received: from localhost (localhost [127.0.0.1]) by daleenterprise.com (Postfix) with ESMTP id 727445F44FD; Fri, 15 Feb 2008 15:37:05 -0500 (EST) Received: from daleenterprise.com ([127.0.0.1]) by localhost (daleenterprise.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21368-02; Fri, 15 Feb 2008 15:37:01 -0500 (EST) Received: from [10.1.100.11] (daleenterprise.com [10.1.100.11]) by daleenterprise.com (Postfix) with ESMTP id CDF5F5F44E7; Fri, 15 Feb 2008 15:37:01 -0500 (EST) In-Reply-To: References: <971575499.20080209153315@marcus-boerger.de> <47B56334.9070007@zend.com> <1203070677.10500.12.camel@localhost.localdomain> <47B568A6.9060704@zend.com> <1158304008.20080215122414@marcus-boerger.de> <47B58B5D.9020301@zend.com> <47B5917C.5050606@sci.fi> <81BAF097-DF7D-4A3D-AED6-A22C912C83DB@daleenterprise.com> <47B5A3E5.4020006@zend.com> <47B5A476.602@sci.fi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8--685162093" Message-ID: <5D47F679-1147-42F0-996D-70411F197050@daleenterprise.com> Cc: jani.taskinen@iki.fi, "PHP Internals List" Date: Fri, 15 Feb 2008 15:37:00 -0500 To: Chris Stockton Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) MTA-Interface: amavisd-new-2.3.3 (2005-08-22) + Maia Mailguard 1.1.0 at daleenterprise.com X-Spam-Scanned: using SpamAssassin 3.1.7 (2006-10-05) at daleenterprise.com X-Virus-Scanned: using ClamAV 0.88.6 (2006-11-05) at daleenterprise.com Subject: Re: [PHP-DEV] [RFC] Conditional INI support From: buildsmart@daleenterprise.com (BuildSmart) --Apple-Mail-8--685162093 Content-Type: multipart/alternative; boundary=Apple-Mail-7--685162259 --Apple-Mail-7--685162259 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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 > 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 --Apple-Mail-7--685162259 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 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=A0language, = just=A0something=A0covering 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...


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.
=A0We have to keep the ini files = as simple as possible, this isn't the job of
=A0the = ini file.

=A0--Jani


=A0Dmitry Stogov = kirjoitti:


The idea makes sense too, but = mix of C and SH syntax isn't good.

Dmitry.

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


Dmitry Stogov kirjoitti:
I think it will work.
#ifdef UNDEFINED > 5=A0 (false)
#ifdef UNDEFINED <=3D 5 (true)
(but anyway I think it is possible to find out an = unclear condition)
Dmitry.
Marcus Boerger wrote:
Hello Dmitry,

=A0 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 >=3D 6
#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
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
Why? Don't make php.ini = parsing any more complex than it already
Any string which can pass as = constant will have that constant's (or
anyway? And why do you need = defined() ??? (examples please? :)

--Jani

=



Best = regards,
=A0Marcus

=
--
PHP = Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



-- = Dale




=A0--
=A0PHP = Internals - PHP Runtime Development Mailing List
=A0To = unsubscribe, visit: http://www.php.net/unsub.php



--=A0
PHP = Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



-- Dale


 =

= --Apple-Mail-7--685162259-- --Apple-Mail-8--685162093 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFHtffs0hzWbkf0eKgRAgdjAJ9SBOiSe21TGKG+VsAyEARxcWTJ9QCfa2Jr eC21Smk8uswxgglj+57Wo5w= =2sy8 -----END PGP SIGNATURE----- --Apple-Mail-8--685162093--