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 <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to