> 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