Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103875 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 87024 invoked from network); 29 Jan 2019 12:42:23 -0000 Received: from unknown (HELO mail1.25mail.st) (206.123.115.54) by pb1.pair.com with SMTP; 29 Jan 2019 12:42:23 -0000 Received: from [10.0.1.70] (unknown [49.48.244.101]) by mail1.25mail.st (Postfix) with ESMTPSA id BDD016049C; Tue, 29 Jan 2019 09:21:28 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) In-Reply-To: Date: Tue, 29 Jan 2019 16:21:24 +0700 Cc: Dan Ackroyd , Rowan Collins , Benjamin Morel , Thomas Hruska , PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: <0617D8F3-2380-4DB7-A641-04854B14B4D6@koalephant.com> References: To: Girgias X-Mailer: Apple Mail (2.3445.102.3) Subject: Re: [PHP-DEV] Deprecation ideas for PHP 8 From: php-lists@koalephant.com (Stephen Reay) > On 29 Jan 2019, at 07:13, Girgias wrote: >=20 > On Thu, 24 Jan 2019 at 01:25, Dan Ackroyd = wrote: >=20 >> On Wed, 23 Jan 2019 at 17:25, Girgias = wrote: >>=20 >>> I understand the rationale for functional programming, may I ask >>> in your opinion should PHP have built-in functions for arithmetic >>> operations so that it can be used in such a way without needing = userland >>> implementations? >>=20 >> No, but only I'd much strongly prefer we have some syntax for defined >> 'short closures' ala Javascript: >>=20 >> $values =3D [1, 2, 3]; >> $bar =3D array_map($x =3D> $x + 1, $values); >>=20 >> // $values =3D=3D=3D [2, 3, 4]; >>=20 >> as those cover much more than the basic arithmetic operations, are >> nice and readable after you've used them a few times. >>=20 >> cheers >> Dan >> Ack >>=20 >=20 > I didn't even know you could omit parenthesis in JS closures, the more = you > know. > But it seems like there is already a Draft for an RFC for short = closures in > PHP but > that one seems to have come to a halt. >=20 > I've realised I didn't go through array functions so just gonna bring = them > up for the sake of not creating a new thread: >=20 >=20 > - key_exist - alias of array_key_exist > A GitHub search brings up 276 078 results where there are some = userland > usage but also a whole lot of unit tests usage > https://github.com/search?l=3DPHP&p=3D1&q=3Dkey_exists&type=3DCode > - pos - alias for current > Can't seem to get any meaningful result by searching on GitHub as it > picks up more or less anything which contains pos > https://github.com/search?l=3DPHP&q=3Dpos%28&type=3DCode > - sizeof - alias of count > A Github search brings up 1 617 789 results with lots of userland = usage > but also a bit of unit testing > https://github.com/search?l=3DPHP&p=3D1&q=3Dsizeof&type=3DCode >=20 > And then there is *array_multisort* a function which has a signature = which > isn't even possible in userland code. > (https://secure.php.net/manual/en/function.array-multisort.php). > Other than the fact that this function's documentation isn't totally > correct in my opinion I did a Github search to see if people use it. >> =46rom what I've seen in the search results [1], around 620k, it is = only used > in phpt unit tests and a unit test of a parser. >=20 > Now, I don't think a function which doesn't follow normal function > signature converntion (or isn't even possible) shouldn't really be = part of > the language. > Moreso that it seems barely anybody uses it. > What's people opinion on deprecating array_multisort ? >=20 > [1] > = https://github.com/search?l=3DPHP&o=3Ddesc&p=3D1&q=3Darray_multisort&s=3D&= type=3DCode >=20 > George P. Banyard My opinion on deprecating array_multisort is: don=E2=80=99t.=20 Plenty of provided functionality exists specifically because it=E2=80=99s = stuff that=E2=80=99s not feasible or not efficient to do in userland. Given the fairly unique capabilities of array_multisort, what is your = suggested replacement for the half-million instances on GitHub alone = (lets not forget that GitHub is not the single repository of all code = ever written, and the search you=E2=80=99ve referenced is only public = repos)? If array_multisort is viable for deprecation, surely array_fill is as = well? At least that one is replaceable with a simple userland = implementation. What about array_rand? Or array_product - that has a = paltry 31K results on GitHub. Or array_chunk, that=E2=80=99s only 2/3 as = many results as for array_multisort. Heck, why not remove all built in functions and just force everyone to = write the entire runtime from scratch in userland code? In case you didn=E2=80=99t realise, this is sarcasm at the extreme, = because your given reasons to support deprecation are absurd.