... like the hidden array element: http://3v4l.org/6uFqf
... like the hidden object property: http://3v4l.org/RPJXH
Marc
Hi,
... like the hidden array element: http://3v4l.org/6uFqf
... like the hidden object property: http://3v4l.org/RPJXH
Don't know if it's related or not, but sure feels like a bug i posted
a while ago: https://bugs.php.net/bug.php?id=67640
thanks!
Robin
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.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
... like the hidden array element: http://3v4l.org/6uFqf
... like the hidden object property: http://3v4l.org/RPJXHThe 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
From: julienpauli@gmail.com [mailto:julienpauli@gmail.com] On Behalf Of Julien Pauli, Sent: Tuesday, October 14, 2014 10:05 AM
Hi!
... like the hidden array element: http://3v4l.org/6uFqf
... like the hidden object property: http://3v4l.org/RPJXHThe 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
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
Hi!
Please correct me if I'm wrong but object properties should be strings
in all cases.
In all cases where they are assigned as object properties. If they were
produced by other means, it can be different.
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:
While for objects all keys are strings, for arrays keys '123' and 123
are the same - integer 123.
|$obj = (object)array('123' => '456');
var_dump($obj);
Here the array had numeric index, so the object property became numeric
index too. The alternative for this would be for this operation to scan
through whole array and convert each key from numeric to string, which
given how exotic is this case seems to be a waste of time.
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
You seem to ignore the fact that you still have to go through the whole
array and scan each key and convert some of them, and all this work in
99.99999% of real cases is for nothing and is useful only in an invented
abstract example. So the question is - would this check be useful for
anything than fixing an exotic case which nobody ever encounters in
practice?
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.
No. Performance is a feature. If we can have something that works for
all practical uses and is fast, it is much preferable than having
something that works in 100% of theoretical invented corner cases and in
practice is too slow to be useful since it is ridden with useless checks
just to cover the theoretical corner cases. So the question is - do we
really need this working that way for anything useful? If not, then
there's no point in fixing it, if yes - there is.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
|$obj = (object)array('123' => '456');
var_dump($obj);
Here the array had numeric index, so the object property became numeric
index too. The alternative for this would be for this operation to scan
through whole array and convert each key from numeric to string, which
given how exotic is this case seems to be a waste of time.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
You seem to ignore the fact that you still have to go through the whole
array and scan each key and convert some of them, and all this work in
99.99999% of real cases is for nothing and is useful only in an invented
abstract example. So the question is - would this check be useful for
anything than fixing an exotic case which nobody ever encounters in
practice?
I think you may be over-estimating the performance impact of this somewhat.
For the array-to-object conversion, no scanning is necessary, since the
internal implementation already knows which keys are integers and which
strings. For the vast majority of cases, the array passed in will have
no integer keys, so overhead is effectively zero; for an array
containing numeric keys, the overhead will be the time taken to create a
string property key for each integer array key. By your own argument,
this situation is sufficiently rare that very few people will be affected.
For the object-to-array conversion, there will be an additional
overhead, which will be proportional to the number of properties on the
object. I would strongly suspect that most objects have very few
properties, and very few property names would pass a simple test of "is
first character a digit" but subsequently fail the full is numeric test.
So again, the major part of the overhead would only be felt by those
rare people who encounter this issue.
There is still complexity overhead here, obviously, so this doesn't
completely nullify your point.
--
Rowan Collins
[IMSoP]
Hi!
For the array-to-object conversion, no scanning is necessary, since the
internal implementation already knows which keys are integers and which
strings. For the vast majority of cases, the array passed in will have
Could you explain this? How you know which keys are integers and which
strings without actually checking them?
object. I would strongly suspect that most objects have very few
properties, and very few property names would pass a simple test of "is
first character a digit" but subsequently fail the full is numeric test.
You still have to scan through all of them, even if they have no digits
at all.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
For the array-to-object conversion, no scanning is necessary, since the
internal implementation already knows which keys are integers and which
strings. For the vast majority of cases, the array passed in will haveCould you explain this? How you know which keys are integers and which
strings without actually checking them?
He means there's no additional effort required to know whether the key of each element is a string or not, because that work has already been done at the insert/update stage.
object. I would strongly suspect that most objects have very few
properties, and very few property names would pass a simple test of "is
first character a digit" but subsequently fail the full is numeric test.You still have to scan through all of them, even if they have no digits
at all.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/