Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93646
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.44 as permitted sender)
MIME-Version: 1.0
References: <CAJaRsPtPT0Jtn5MNnMuEO4o79oj1Anw63v1PdKhuVG4CD2qw-g@mail.gmail.com>
 <CADyq6sLuzfJoE5dG795Er1Dq2ThWeGxS7taMwyo1qbn-zejxSg@mail.gmail.com>
 <CAJaRsPsGqskOts8E=3YYa2GctgfO65tuZQL3i6a6zXGPB=vf0g@mail.gmail.com> <CADyq6s+X2DrPPRh8vh+kc3A6o1KBpEkuZVt70S6Sxn6uS8y+Aw@mail.gmail.com>
In-Reply-To: <CADyq6s+X2DrPPRh8vh+kc3A6o1KBpEkuZVt70S6Sxn6uS8y+Aw@mail.gmail.com>
Date: Tue, 31 May 2016 02:14:20 +0000
Message-ID: <CAJaRsPsyR=ZEbXJ4cSZ7N_WxAfq7wbbduCPdigoapxBHxc-bzQ@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP Internals <internals@lists.php.net>, Jeremy Mikola <jmikola@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140fd20de2c8a053419eecc
Subject: Re: [PHP-DEV] [RFC Discussion] array_change_keys()
From: colinodell@gmail.com ("Colin O'Dell")

--001a1140fd20de2c8a053419eecc
Content-Type: text/plain; charset=UTF-8

>
> Ported to https://github.com/Ocramius/array_change_keys-benchmark, thanks!
>

I've updated the RFC's benchmarks based on your tool.  They confirm that
array_change_keys is faster than array_combine but slower than foreach (in
most cases).  Thanks for helping with this!


> No, but I really don't care about the other functions. If something
> doesn't support a `Traversable` in today's jungle of Generators and
> asynchronous processing.
>

While generators and async processing are nice, I don't think that means we
have to avoid work that doesn't fall under that umbrella.  Or Is there
perhaps something unique about this particular function that warrants
Traversable support whereas other functions don't?


> 3. Purpose of the array_*() function is immediately obvious.
>>
>
> Disagree, as mentioned in few edge cases in other responses (something
> about numerical keys, IIRC: can't find the actual reply)
>

I believe you're referring to the questions about returning null, invalid,
or duplicate keys.  As I mentioned in my responses to those questions,
array_change_keys() was expressly designed to behave *EXACTLY* like
existing functions (such as array_flip):

 - Returning null as a key is not allowed (array_flip disallows this).
 - If you return a duplicate key, only the last value to return it will be
kept (just like calling array_flip with duplicate values or running:
$arr['foo'] = 1; $arr['foo'] = 2;)

Somebody else asked whether they could "return null" to use an automatic
numeric key - I responded "no" because "$arr[null]" is not the same as
"$arr[]".

*Again, this RFC does NOT introduce any new edge cases or quirks.*  I'd
therefore respectfully ask that you re-consider this.


>  Function composition can be applied also with a userland implementation.
> My main issue with this is that it doesn't need to exist in *core*. Doesn't
> mean that it can't exist in userland ;-)
>

One could argue that array_change_key_case(), array_column(), random_int(),
password_hash(), and others don't strictly need to exist in core either.
However, they were all included because someone (or some group) felt that
they provided enough value to PHP developers and/or that their usefulness
outweighed the hassle of a userland implementation.  All I ask is that we
give this RFC the same consideration - and if you still feel the same I
fully accept that :)

I appreciate the feedback as always and have updated the RFC with several
of these discussion points.

Colin

--001a1140fd20de2c8a053419eecc--