Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
To: =?UTF-8?Q?Pedro_Magalh=c3=a3es?= <mail@pmmaga.net>
References: <CAJd4=YYAuN295mu91rVFBGbiw-ZNFegv5bhWHCwX9=fXh_MyOA@mail.gmail.com>
 <CAJd4=YZQ2vd2f_q+RqVLTLhDKGV+gaQsYG+Ncf79JZQ7RWuwcg@mail.gmail.com>
 <3d5cfa50-5f5d-5633-99ad-052a6b5ac599@gmail.com>
 <CAJd4=YbBRS3SbF3XLBVMPQzBY0Z5tFQNwmnHg9U6t14sA9A7cA@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <466f3491-321f-2aca-ea5a-4128b07356df@gmail.com>
Date: Sat, 4 Mar 2017 16:09:35 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAJd4=YbBRS3SbF3XLBVMPQzBY0Z5tFQNwmnHg9U6t14sA9A7cA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------E925367DB51CAD7AAF2D5339"
Subject: Re: [PHP-DEV] Re: On arrays starting with a negative index
From: rowan.collins@gmail.com (Rowan Collins)

--------------E925367DB51CAD7AAF2D5339
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Pedro,

On 02/03/2017 23:10, Pedro Magalhães wrote:
>
>     Would other behaviour also be affected?
>
>     For instance:
>
>     $foo = [ -2 => true ];
>     $foo[] = true;
>     $foo[] = true;
>     var_dump($foo);
>
>     If so, this is a much wider BC break; if not, why not?
>
>
> It would indeed. Internally, nNextFreeElement is initialized with 0 
> and updates on larger values. In the PR 
> (https://github.com/php/php-src/pull/2383/files#diff-fd78a0a3f78ea28c6907f907f25b908eR798) I'm 
> allowing it to be set to a negative value if it is the first element.

I haven't built with the patch to check, but have you checked it behaves 
correctly with other combinations? For instance [-10 => true, -5 => 
true, true] or ['string_key' => true, -10 => true, true]


> I completely agree on the impact of this change. But I also believe 
> that this behaviour would be preferable.

I broadly agree that the proposed behaviour would be preferable in 
itself. Unfortunately, in a language with 20 years of history, and 
millions of lines of deployed code, we don't have the luxury of looking 
at behaviour in isolation, we have to think about the consequences of 
change as well as the end result.

Would you be willing to draft an RFC for this change? If you're not 
familiar with the process, have a look at this: 
https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process

You'll need to make the case for the change, and try to consider all the 
angles. For instance:

- Exactly what behaviour will change, and how? We already have three 
different things that are affected, and there may well be others.
- What code might rely on the current behaviour? What kind of bugs might 
such code exhibit if it's not updated after the change? How can users 
write code that will work the same before and after the change?
- On the other side, what are the benefits of the change? What is the 
harm caused by the current behaviour, e.g. potential for bugs or mistakes?

This may seem like a lot of work for such a simple patch, but the more 
we discuss it, the clearer it becomes that this would be a significant 
language change, so we need to make sure it's considered properly.

Regards,

-- 
Rowan Collins
[IMSoP]


--------------E925367DB51CAD7AAF2D5339--