Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77949
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.91 as permitted sender)
Message-ID: <543CCFEA.2080908@sugarcrm.com>
Date: Tue, 14 Oct 2014 00:25:30 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Marc Bennewitz <php@mabe.berlin>, 
 PHP Internals List <internals@lists.php.net>
References: <543C9E9F.80804@mabe.berlin>
In-Reply-To: <543C9E9F.80804@mabe.berlin>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Possibilities to fix some really poor behaviors in
 PHP7
From: smalyshev@sugarcrm.com (Stas Malyshev)

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/