Hi Pierre,
I will go ahead and enter a Bug report for this in a bit ('cause there's
definitely a bug), just so it's in the official place (preferred, I guess?)
and doesn't keep going here on the list. :-)
----- Original Message -----
From: "Pierre"
Sent: Monday, August 14, 2006
> Hello,
>
> > While I agree the change should be carefully reviewed, I must wonder
> > why the millions upon millions of lines of code in 4.x are going to be
> > ignored here...
> >
> > What rationale is there for breaking the BC?
> >
> > Obviously you think it should be broken -- I just don't understand
why...
>
> I did not say it should be broken. All I said (and confirmed by
> Andrei) is that we should first sit down and figure out what, how and
> when we can/should change something. It seems to me as the sanest
> attitude given the insane amount of senseless changes.
>
> There is no need to push a patch just to bring another entry to this
> changelog. As I already suggested, we can work together on a proposal
> and bring it to a conclusion.
Just to be sure, you are just talking about the array_count_values()
function and not the is_numeric... stuff? Since the array function bug has
nothing to do with is_numeric -- since as I've said, it shouldn't be there.
Andrei confirmed about changing (or, not) *array_count_values* or
is_numeric...? I only saw the list e-mail about is_numeric...
This discussion is unbelievable to me, with being concerned about changing
clearly buggy behavior. Related to what I asked previously, will you guys
"un-fix" any bug that someone says broke their code by being fixed? In that
case, why fix any (non-security) bugs, since doing so can obviously change
existing PHP code?
Again, if it wasn't clear previously, YOU (not Pierre! :-)) caused the bug 2
years ago in file version 1.273 (PHP 5.0.2) by improperly fixing another
bug! Not 3 months before that, the changelog comment stated that you "need
to go through this file and find any stuff that relies on this change" (abou
t "hash" function behavior moving to "symtable"). Very simple to do, and it
would've prevented these other bug reports (and this thread...).
No matter what is done (or nothing), the function will behave differently
than either 4.0-5.0.1, or 5.0.2-present. No, this bug didn't exist before
5.0.2 (though the other ones did in 5.0.0).
Why do you guys think the HANDLE_NUMERIC() macro, that's used in "symtable"
functions, is named what it is? Because it does what the name suggests
*perfectly/error-free*.
Here is even more stuff that's getting screwed up (signs):
var_dump(array_count_values(array('-000', '-01', '+123')));
array(3) {
[0]=>
int(1)
[-1]=>
int(1)
[123]=>
int(1)
}
So the current mess of code, DOES handle 1) leading 0's; DOESN'T handle 1)
leading whitespace, 2) leading "-" with one or more 0's, 3) leading "+"
"symtable" functions with HANDLE_NUMERIC(), DOES handle... Oh wow,
everything! :-)
Out of array keys/indexes, array_combine, array_flip, array_fill_keys,
array_key_exists, and array_count_values, this is the only one that handles
these values differently -- WHY?! (Oh, I can answer: the others use the
"symtable" functions instead of is_numeric... + other crap. Geez.)
> --Pierre
Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
