Hi internals!
I'd like to get some attention to bug #60039 1. It is about the
behavior of array_key_exists with "unusual" keys like floats, bools
and resources. Currently array_key_exists throws a warning if such a
key is passed. isset() on the other hand (and native array accesses in
general) treat them as valid keys, with floats being converted to ints
and bools and resources treated just like ints.
I would like to see array_key_exists behave consistent with
isset($array[$key]) / $array[$key]. The bug has a patch attached that
does this.
I don't think that this change has any BC impact as it only removes warnings.
Nikita
push
On Fri, Nov 11, 2011 at 10:40 PM, Nikita Popov
nikita.ppv@googlemail.com wrote:
Hi internals!
I'd like to get some attention to bug #60039 1. It is about the
behavior of array_key_exists with "unusual" keys like floats, bools
and resources. Currently array_key_exists throws a warning if such a
key is passed. isset() on the other hand (and native array accesses in
general) treat them as valid keys, with floats being converted to ints
and bools and resources treated just like ints.I would like to see array_key_exists behave consistent with
isset($array[$key]) / $array[$key]. The bug has a patch attached that
does this.I don't think that this change has any BC impact as it only removes warnings.
Nikita
Hi,
push
On Fri, Nov 11, 2011 at 10:40 PM, Nikita Popov
nikita.ppv@googlemail.com wrote:Hi internals!
I'd like to get some attention to bug #60039 1. It is about the
behavior of array_key_exists with "unusual" keys like floats, bools
and resources. Currently array_key_exists throws a warning if such a
key is passed. isset() on the other hand (and native array accesses in
general) treat them as valid keys, with floats being converted to ints
and bools and resources treated just like ints.I would like to see array_key_exists behave consistent with
isset($array[$key]) / $array[$key]. The bug has a patch attached that
does this.I don't think that this change has any BC impact as it only removes warnings.
To me, it feels similar to the Array->String conversion:
It is one of those implicit conversions that is almost always indicating a bug.
Therefore I would rather have both throw warnings than none of them.
So -1 from me for the proposed unification.
Nikita
--
--
Etienne Kneuss
http://www.colder.ch
2011/11/18 Etienne Kneuss colder@php.net:
Hi,
push
On Fri, Nov 11, 2011 at 10:40 PM, Nikita Popov
nikita.ppv@googlemail.com wrote:Hi internals!
I'd like to get some attention to bug #60039 [1]. It is about the
behavior of array_key_exists with "unusual" keys like floats, bools
and resources. Currently array_key_exists throws a warning if such a
key is passed. isset() on the other hand (and native array accesses in
general) treat them as valid keys, with floats being converted to ints
and bools and resources treated just like ints.I would like to see array_key_exists behave consistent with
isset($array[$key]) / $array[$key]. The bug has a patch attached that
does this.I don't think that this change has any BC impact as it only removes warnings.
To me, it feels similar to the Array->String conversion:
It is one of those implicit conversions that is almost always indicating a bug.Therefore I would rather have both throw warnings than none of them.
So -1 from me for the proposed unification.
Same opinion here. I do prefer not having such implict data repair.
--
Regards,
Felipe Pena
2011/11/18 Etienne Kneuss colder@php.net:
To me, it feels similar to the Array->String conversion:
It is one of those implicit conversions that is almost always indicating a bug.Therefore I would rather have both throw warnings than none of them.
So -1 from me for the proposed unification.
Same opinion here. I do prefer not having such implict data repair.
Thanks for your answers
This is not about whether or not PHP's current behavior towards float
keys is good or not - it is existing behavior. This is about making
isset($array[$key]) and array_key_exists($key, $array) behave the same
(apart from the null value difference).
We could obviously make the unification work the other way around,
i.e. remove float, bool, resource and null support for array keys, but
I am sure that this will only be a call for the angry mob, which
expected that their 14.0 key behaves just like a 14 one (which kinda
makes sense in a PHP environment).
Nikita