Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78065
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender)
Message-ID: <543D8E87.9050606@sugarcrm.com>
Date: Tue, 14 Oct 2014 13:58:47 -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> <543CCFEA.2080908@sugarcrm.com> <543D7D18.9010100@mabe.berlin>
In-Reply-To: <543D7D18.9010100@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!

> 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/