RE: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
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
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
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
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
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.9% 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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
On 14/10/2014 21:58, Stas Malyshev wrote:
|$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.9% 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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
On 15 Oct, 2014, at 9:23 am, Stas Malyshev smalys...@sugarcrm.com wrote: 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? 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Possibilities to fix some really poor behaviors in PHP7
... like the hidden array element: http://3v4l.org/6uFqf ... like the hidden object property: http://3v4l.org/RPJXH Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
