> From: julienpa...@gmail.com [mailto:julienpa...@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 <smalys...@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


Reply via email to