RE: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
| From: | Christian Stoller | Date: | Wed, 15 Oct 2014 06:33:07 +0000 |
| Subject: | RE: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78087@lists.php.net to get a copy of this message | ||
> From: julienpauli@gmail.com [mailto:julienpauli@gmail.com] On Behalf Of Julien Pauli, Sent:
> Tuesday, October 14, 2014 10:05 AM
>
> On Tue, Oct 14, 2014 at 9:25 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>> Hi!
>>
>>> ... like the hidden array element:
>>> http://3v4l.org/6uFqf
>>> ... like the hidden object property:
>>> http://3v4l.org/RPJXH
>>
>> The issue seems to be that array lookup always looks for numeric results
>> when looking for numeric-like keys. But when adding property, the
>> numeric check is not done since properties are not supposed to be
>> numeric. Thus, when converting the object to array, the property named
>> "123" becomes inaccessible, because in array it is supposed to be under
>> number 123.
>>
>> We could, of course, add numeric checks to properties, but it would slow
>> things down only to serve very narrow use case with hardly any legit
>> uses. We could also rewrite hashtable with numeric keys instead of
>> string keys when doing conversion, but again that would be significant
>> slowdown for a very rare use case. Not sure it's worth it.
>
> I agree that fixing a strange behavior - very little people know about
> and very few little people use in real case - involving performance
> penalty for any other use case ; should be a -1 of course.
>
> Let's say the behavior is here "by design" ;-)
>
> Julien.Pauli
>
If it is "by design", it should be documented in http://php.net/manual/en/language.types.array.php#language.types.array.casting
and maybe at a corresponding place on http://php.net/manual/en/language.types.object.php