On 14.10.2014 09:25, Stas Malyshev 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.
Please correct me if I'm wrong but object properties should be strings
in all cases.
So all properties set should be converted to string means the following
should be equal but isn't and I don't see any performance issues forcing
strings here:
|$obj = (object)array('123' => '456');
var_dump($obj);
var_dump($obj->{'123'}); // ||Notice: Undefined property: stdClass::$123|
|var_dump($obj->{123});| |// ||Notice: Undefined property:
stdClass::$123|
For the case of object to array conversion a numeric check could be very
improved by simply check if the first character between 0-9 before
starting the complete numeric check. That would be very fest and it
produces right results. It's poor to say "... very narrow use case with
hardly any legit uses ..." in programming languages. In my opinion the
right result have to be the first goal and performance optimization is
something to keep in mind but should never produce wrong results.
Marc
