Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78068
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
Message-ID: <543D9580.60202@gmail.com>
Date: Tue, 14 Oct 2014 22:28:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <543C9E9F.80804@mabe.berlin> <543CCFEA.2080908@sugarcrm.com> <543D7D18.9010100@mabe.berlin> <543D8E87.9050606@sugarcrm.com>
In-Reply-To: <543D8E87.9050606@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Possibilities to fix some really poor behaviors in
 PHP7
From: rowan.collins@gmail.com (Rowan Collins)

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.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]