[PHP-DEV] Constants

[Andi Gutmans]

Hi,

I'm trying to wrap up the class wide constants in ZE2. I implemented them 
so that class wide constants are case-sensitive. I think in general, 
although ZE1 allows you to define case-insensitive constants it's better 
for performance and for general esthetics.

I have two issues I'd like to get some input on:

a) There are almost no constants in PHP which are case-insensitive (which 
aren't user land defined with define()).  Actually the only ones I could 
find are in the Zend Engine such as TRUE & FALSE which makes sense. All PHP 
extensions which use REGISTER_LONG_CONSTANT() and friends use the CONST_CS 
(case-sensitive flag). I would like to change these macros to *always* 
register as case-sensitive. Unless I missed some extensions this shouldn't 
bite anyone as all extensions seem to use CONST_CS. Of course I won't 
change the special purpose constants such as TRUE & FALSE which are today 
registered as case-insensitive. What do you guys think?

b) REGISTER_MAIN_LONG_CONSTANT() and friends (notice the MAIN) are used to 
register constants which shouldn't be unloaded when the PHP extension is 
unloaded. I can't think of many cases where this is applicable. For 
example, if the pspell extension is unloaded I think all of its constants 
should be unloaded too. However, this extension is one example of an 
extension using the _MAIN_ macro. Can each of you check your extension and 
move to REGISTER_LONG_CONSTANT() unless there's a good reason not to?

Thanks,

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Constants

[Evan Nemerson]

I was thinking about putting together a list of constants, their purpose, 
what version of PHP they initially appeared in, etc.

So far, I have figured out a function called "REGISTER_LONG_CONSTANT" is 
used, or a constant is defined in the source with a name that has a 
preceeding "PHP_" (eg "PHP_RAND_MAX"- which is 2^31??? why not 2^32? sorry 
off the point.) Are there any other ways? Are these ways inaccurate?

Please reply to my e-mail address ([EMAIL PROTECTED]). I don't subscribe 
to this list.


Evan Nemerson

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

Re: [PHP-DEV] Constants

[Jon Parise]

On Mon, Dec 03, 2001 at 08:24:29PM +0200, Andi Gutmans wrote:

> a) There are almost no constants in PHP which are case-insensitive (which 
> aren't user land defined with define()).  Actually the only ones I could 
> find are in the Zend Engine such as TRUE & FALSE which makes sense. All PHP 
> extensions which use REGISTER_LONG_CONSTANT() and friends use the CONST_CS 
> (case-sensitive flag). I would like to change these macros to *always* 
> register as case-sensitive. Unless I missed some extensions this shouldn't 
> bite anyone as all extensions seem to use CONST_CS. Of course I won't 
> change the special purpose constants such as TRUE & FALSE which are today 
> registered as case-insensitive. What do you guys think?

I think that makes a lot of sense.  Go for it.
 
> b) REGISTER_MAIN_LONG_CONSTANT() and friends (notice the MAIN) are used to 
> register constants which shouldn't be unloaded when the PHP extension is 
> unloaded. I can't think of many cases where this is applicable. For 
> example, if the pspell extension is unloaded I think all of its constants 
> should be unloaded too. However, this extension is one example of an 
> extension using the _MAIN_ macro. Can each of you check your extension and 
> move to REGISTER_LONG_CONSTANT() unless there's a good reason not to?
 
I can't think of a good reason why an extension should leave any
remnants of itself lying around once it's unloaded.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Information Technology (2001)
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Constants

[Andrei Zmievski]

On Mon, 03 Dec 2001, Andi Gutmans wrote:
> Hi,
> 
> I'm trying to wrap up the class wide constants in ZE2. I implemented them 
> so that class wide constants are case-sensitive. I think in general, 
> although ZE1 allows you to define case-insensitive constants it's better 
> for performance and for general esthetics.
> 
> I have two issues I'd like to get some input on:
> 
> a) There are almost no constants in PHP which are case-insensitive (which 
> aren't user land defined with define()).  Actually the only ones I could 
> find are in the Zend Engine such as TRUE & FALSE which makes sense. All PHP 
> extensions which use REGISTER_LONG_CONSTANT() and friends use the CONST_CS 
> (case-sensitive flag). I would like to change these macros to *always* 
> register as case-sensitive. Unless I missed some extensions this shouldn't 
> bite anyone as all extensions seem to use CONST_CS. Of course I won't 
> change the special purpose constants such as TRUE & FALSE which are today 
> registered as case-insensitive. What do you guys think?

Makes sense. I'd also like to request that the engine be able to
distinguish between FOO_BAR and Foo_BAR constants, for example.

> b) REGISTER_MAIN_LONG_CONSTANT() and friends (notice the MAIN) are used to 
> register constants which shouldn't be unloaded when the PHP extension is 
> unloaded. I can't think of many cases where this is applicable. For 
> example, if the pspell extension is unloaded I think all of its constants 
> should be unloaded too. However, this extension is one example of an 
> extension using the _MAIN_ macro. Can each of you check your extension and 
> move to REGISTER_LONG_CONSTANT() unless there's a good reason not to?

I don't think any of mine do this.

-Andrei
* Think digital, act analog. *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Constants

[Andi Gutmans]

At 01:03 PM 12/3/2001 -0600, Andrei Zmievski wrote:
>On Mon, 03 Dec 2001, Andi Gutmans wrote:
> > Hi,
> >
> > I'm trying to wrap up the class wide constants in ZE2. I implemented them
> > so that class wide constants are case-sensitive. I think in general,
> > although ZE1 allows you to define case-insensitive constants it's better
> > for performance and for general esthetics.
> >
> > I have two issues I'd like to get some input on:
> >
> > a) There are almost no constants in PHP which are case-insensitive (which
> > aren't user land defined with define()).  Actually the only ones I could
> > find are in the Zend Engine such as TRUE & FALSE which makes sense. All 
> PHP
> > extensions which use REGISTER_LONG_CONSTANT() and friends use the CONST_CS
> > (case-sensitive flag). I would like to change these macros to *always*
> > register as case-sensitive. Unless I missed some extensions this shouldn't
> > bite anyone as all extensions seem to use CONST_CS. Of course I won't
> > change the special purpose constants such as TRUE & FALSE which are today
> > registered as case-insensitive. What do you guys think?
>
>Makes sense. I'd also like to request that the engine be able to
>distinguish between FOO_BAR and Foo_BAR constants, for example.

Personally I wouldn't write code which gives FOO_BAR and Foo_BAR two 
different meanings but I think you are right that it'd be better and I have 
an idea on how to do it which I'll lay out.
We are only talking about global constants defined with define() as class 
constants are always case sensitive and they can distinguish what you 
mentioned above.
There's one way I can think of in order to fix define(). It has advantages 
and disadvantages. The advantage is that all constant lookups will be much 
faster than they are today (no strtolower() and no memcmp()). The 
disadvantage is that defining constants will be much slower.
What we would do is that instead of adding the name of the constant after 
an strtolower() into the constants hash we would do the following:
- for case-sensitive constants: Add it with the exact same case as the 
definition.
- for case-insensitive constants: Add all possible cases for the constant. 
That means that for a word of length L we'd add at most L*2 keys to the hash.

This solution actually would work very well. It'd would fix the above 
problem and hash lookups would be faster. It would also be a step away from 
case-insensitive constants. It would of course make case-insensitive 
constant definitions much slower but as no C-extensions use them 
(especially after I nuke it) and only about 5 constants in Zend use them it 
should be fine (this is assuming that not many people use the third 
argument of define() which allows them to define case-insensitive constants).

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Constants

[Lars Torben Wilson]

On Wed, 2002-02-13 at 17:22, Evan Nemerson wrote:
> I was thinking about putting together a list of constants, their purpose, 
> what version of PHP they initially appeared in, etc.
> 
> So far, I have figured out a function called "REGISTER_LONG_CONSTANT" is 
> used, or a constant is defined in the source with a name that has a 
> preceeding "PHP_" (eg "PHP_RAND_MAX"- which is 2^31??? why not 2^32? sorry 
> off the point.) Are there any other ways? Are these ways inaccurate?
> 
> Please reply to my e-mail address ([EMAIL PROTECTED]). I don't subscribe 
> to this list.
> 
> 
> Evan Nemerson

I've committed a list of (almost) all predefined constants and classes 
to the phpdoc cvs. There is a bit more work to be done before the list
makes it into the online manual, but you can either check out phpdoc 
from cvs, or view it online here:

  http://cvs.php.net/co.php/phpdoc/en/appendices/predefined.xml?r=1.3

Warning: it's a long list. There are over a thousand predefined 
constants, all told. :)

Comments welcome (from Evan and from anybody else reading this...)


-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


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

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Constants

[Andrei Zmievski]

On Mon, 03 Dec 2001, Andi Gutmans wrote:
> Personally I wouldn't write code which gives FOO_BAR and Foo_BAR two 
> different meanings but I think you are right that it'd be better and I have 
> an idea on how to do it which I'll lay out.
> We are only talking about global constants defined with define() as class 
> constants are always case sensitive and they can distinguish what you 
> mentioned above.

That's fine for me. I want them for the keysym constants in PHP-GTK
(like GDK_KEY_A and GDK_KEY_a). For now I hack around by using
(GDK_KEY__A) for lowercase ones. Which sucks.

> There's one way I can think of in order to fix define(). It has advantages 
> and disadvantages. The advantage is that all constant lookups will be much 
> faster than they are today (no strtolower() and no memcmp()). The 
> disadvantage is that defining constants will be much slower.
> What we would do is that instead of adding the name of the constant after 
> an strtolower() into the constants hash we would do the following:
> - for case-sensitive constants: Add it with the exact same case as the 
> definition.
> - for case-insensitive constants: Add all possible cases for the constant. 
> That means that for a word of length L we'd add at most L*2 keys to the 
> hash.
> 
> This solution actually would work very well. It'd would fix the above 
> problem and hash lookups would be faster. It would also be a step away from 
> case-insensitive constants. It would of course make case-insensitive 
> constant definitions much slower but as no C-extensions use them 
> (especially after I nuke it) and only about 5 constants in Zend use them it 
> should be fine (this is assuming that not many people use the third 
> argument of define() which allows them to define case-insensitive 
> constants).

What about the idea of introducing case-insensitive hashes? Modifying
hash function so that it hashes 'A' and 'a' into the same value.

-Andrei

"The human brain is a wonderful thing. It starts working the moment you
are born, and never stops until you stand up to speak in public. " -- Sir
George Jessel

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Constants

[Andi Gutmans]

At 02:42 PM 12/3/2001 -0600, Andrei Zmievski wrote:
>On Mon, 03 Dec 2001, Andi Gutmans wrote:
> > Personally I wouldn't write code which gives FOO_BAR and Foo_BAR two
> > different meanings but I think you are right that it'd be better and I 
> have
> > an idea on how to do it which I'll lay out.
> > We are only talking about global constants defined with define() as class
> > constants are always case sensitive and they can distinguish what you
> > mentioned above.
>
>That's fine for me. I want them for the keysym constants in PHP-GTK
>(like GDK_KEY_A and GDK_KEY_a). For now I hack around by using
>(GDK_KEY__A) for lowercase ones. Which sucks.

Oh OK.

> > There's one way I can think of in order to fix define(). It has advantages
> > and disadvantages. The advantage is that all constant lookups will be much
> > faster than they are today (no strtolower() and no memcmp()). The
> > disadvantage is that defining constants will be much slower.
> > What we would do is that instead of adding the name of the constant after
> > an strtolower() into the constants hash we would do the following:
> > - for case-sensitive constants: Add it with the exact same case as the
> > definition.
> > - for case-insensitive constants: Add all possible cases for the constant.
> > That means that for a word of length L we'd add at most L*2 keys to the
> > hash.
> >
> > This solution actually would work very well. It'd would fix the above
> > problem and hash lookups would be faster. It would also be a step away 
> from
> > case-insensitive constants. It would of course make case-insensitive
> > constant definitions much slower but as no C-extensions use them
> > (especially after I nuke it) and only about 5 constants in Zend use 
> them it
> > should be fine (this is assuming that not many people use the third
> > argument of define() which allows them to define case-insensitive
> > constants).
>
>What about the idea of introducing case-insensitive hashes? Modifying
>hash function so that it hashes 'A' and 'a' into the same value.

Because some of the keys are case-insensitive and some aren't. Case 
insensitive hashes don't work if you want to mix the keys.
In any case, I think the solution above is a good one because there are 
only 5 constants in the Zend Engine which are case-insensitive.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Constants

[Andrei Zmievski]

On Mon, 03 Dec 2001, Andi Gutmans wrote:
> Because some of the keys are case-insensitive and some aren't. Case 
> insensitive hashes don't work if you want to mix the keys.
> In any case, I think the solution above is a good one because there are 
> only 5 constants in the Zend Engine which are case-insensitive.

I realize that. Perhaps _ex() versions of hash functions could take a
flag indicating which hash function to use. This may come in handy not
just for constants, you know.

-Andrei
* "I'll need daily status reports on why you're so behind." -- Dilbert's boss *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Constants

[Andi Gutmans]

At 02:55 PM 12/3/2001 -0600, Andrei Zmievski wrote:
>On Mon, 03 Dec 2001, Andi Gutmans wrote:
> > Because some of the keys are case-insensitive and some aren't. Case
> > insensitive hashes don't work if you want to mix the keys.
> > In any case, I think the solution above is a good one because there are
> > only 5 constants in the Zend Engine which are case-insensitive.
>
>I realize that. Perhaps _ex() versions of hash functions could take a
>flag indicating which hash function to use. This may come in handy not
>just for constants, you know.

I still don't understand why you think it's suitable. If I want to lookup a 
constant FOO_Bar. How would you know if the hash function you want to use 
is case-sensitive or not?
In any case, you used to be able to specify a different hash function in 
hash_init() but it was never used and for performance reasons we inline'd 
the hash function.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]