Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103808
MIME-Version: 1.0
References: <CAFPFaM+cEa2xFDqvkLQk=Qht3KdcGUCBaCj6JcuQxqLmjnf9Pw@mail.gmail.com>
 <d43d155f-9fd8-ddff-a44b-3dce2b2f6841@cubiclesoft.com> <CAG9XoMTK4j8R6_v++th2wRkdh5GZD4Vd9tKDt9YpXrhYmoH4uA@mail.gmail.com>
 <CAG9XoMRRO0mmfnuYrH5v4eFWOjRea-o0HmwezuWd=HXyOQT6WA@mail.gmail.com> <CALKiJKpfGWMav7hUNCA-FmNjyYuMkZx+=NHSHzwx35eEz+Gt3g@mail.gmail.com>
In-Reply-To: <CALKiJKpfGWMav7hUNCA-FmNjyYuMkZx+=NHSHzwx35eEz+Gt3g@mail.gmail.com>
Date: Wed, 23 Jan 2019 18:25:29 +0100
Message-ID: <CAFPFaMJSKoFv_oSRa6oDJwooXxws_u5-V7wQU6S3AkZinqmv4A@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, Thomas Hruska <thruska@cubiclesoft.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002a17e605802362d3"
Subject: Re: [PHP-DEV] Deprecation ideas for PHP 8
From: george.banyard@gmail.com (Girgias)

--0000000000002a17e605802362d3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

 On Wed, 23 Jan 2019 at 16:23, Dan Ackroyd <Danack@basereality.com> wrote:

> On Tue, 22 Jan 2019 at 20:34, Girgias <george.banyard@gmail.com> wrote:
> >
> >  a list of  functions which seem reasonable to deprecate
>
> > Classes/Objects functions:
> >
> >    - is_a (use instanceof operator)
>
> This is a fundamentally bad idea.
>
> Functions can be passed around as functions, operators cannot be,
> which makes it easier to composite functionality together with
> functions than with operators.
>
> The main reason to use operators at all is to improve readability.
> i.e. `$x =3D $y + 2;` is easier to scan-read than `$x =3D plus($y, 2);`
> (and I'm not sure the instanceof operator actually achieves this aim.)
> but for when you want to be able to pass a function as a parameter,
> then functions are much more powerful.
>

> The same is true for floatval, intval etc.
>

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?


>
> > Function handling functions:
> >
> >    - call_user_func (invoke directly)
> >    - call_user_func_array (arguments can be provided with the splat
> >    operator (...) as of PHP 5.6
> >    - forward_static_call (same reason as call_user_func)
> >    - forward_static_cal_array (same reason as call_user_func_array)
> >    - func_get_arg (seems unnecessary as of PHP 5.6 with variadic
> functions
> >    (splat operator))
> >    - func_get_args (same reason as func_get_arg)
> >    - func_num_args (same reason as func_get_arg)
>
> btw this RFC https://wiki.php.net/rfc/consistent_callables probably
> needs to be worked on before all the different ways of calling
> 'callables' is interchangeable anyway.
>

Now that's a compelling reason where I can get behind not doing so.


On Wed, 23 Jan 2019 at 17:19, Thomas Hruska <thruska@cubiclesoft.com> wrote=
:

> I've run a set of searches against GitHub code repos.
>
> The numbers below are just generic metrics of usage and reloading search
> result pages caused result counts to vary extremely widely.  I didn't
> look too in-depth at each result set beyond getting a number and a
> general feel.
>
>
Cheers for doing this Thomas.

>     - func_get_args (same reason as func_get_arg)
>
> https://github.com/search?l=3DPHP&o=3Ddesc&q=3Dfunc_get_args&s=3Dindexed&=
type=3DCode
>
> 9.2 million results.
>
> Oh, and the first search result that turned up for me looks fun:
>
>
> https://github.com/phonetworks/graphjs-server/blob/94d4a672e12a3b0b7626d8=
c74110b72f44d564c7/src/GraphJS/Router.php
>
>          self::initSession(...\func_get_args());
>
> An elegant (and yet slightly horrifying) one-liner crushes whatever
> argument you seemed to have about the splat operator:  The author used
> both.
>

Now this is an unexpected result on which I'll see myself beaten.

I'm not in favor of removal of these functions.  While *I* don't use
> them, lots of people still use them in conjunction with array_map() and
> similar callback-oriented functions.  I'd rather see them be optimized
> within specific contexts such as array_map() for significantly improved
> performance *first* before recommending deprecation.
>
>
It has more or less already been established that deprecating those
function is pretty
much impossible in the current state.

>     - gettype (more on this later [1])
>
> https://github.com/search?l=3DPHP&o=3Ddesc&q=3Dgettype&s=3Dindexed&type=
=3DCode
>
> 9.3 million results.  However, most results seem to be classes with a
> method called getType(), so those again throw off an accurate global coun=
t.
>

I remember encountering this issue while I was first writting this email a
month ago and couldn't
get meaningfull results.


> > Maths functions aliases:
> >
> >     - getrandmax
>
> Shouldn't that have a comment like "(use mt_getrandmax() instead)"?
>

It should,


> >     - rand (use mt_rand instead)
> >     - srand (alias of mt_srand as of PHP 7.1)
>
> Most usages from searches seem to be using the mt_...() functions
> already anyway.
>

Good to know

>     - is_writeable =E2=80=94 Alias of is_writable
>
> https://github.com/search?l=3DPHP&o=3Ddesc&q=3Dis_writeable&s=3Dindexed&t=
ype=3DCode
>
> https://github.com/search?l=3DPHP&o=3Ddesc&q=3Dis_writable&s=3Dindexed&ty=
pe=3DCode
>
> 629,500 vs. 3.65 million results.
>
> (On Google:  1.19 million vs. 6.2 million results for the words
> writeable vs. writable.)
>
> Deprecating this alias seems petty.  Users currently don't have to look
> up the function at the moment.  Removing the alias will cause EVERYONE
> to look up the function to be sure they remember how to correctly spell
> it to avoid the deprecation warning.
>

It may same petty but it was just an idea.
Seems like it's to big of a hassle to convert.


> Old signatures:
> >
> >     - implode (historical signature)
>
> Impossible to run a search for this.
>

Understandable that this is impossible to search for.


>
> > Controversial idea:
> >
> >     - deprecate array function creation (array())
>
> https://github.com/search?l=3DPHP&o=3Ddesc&q=3Darray&s=3Dindexed&type=3DC=
ode
>
> 71.1 million results.
>
> No.
>
> Also, array() is not a function.  It's a keyword with performance on-par
> with [].
>
> http://php.net/manual/en/reserved.keywords.php
>
> I also prefer array() over [].  It's more readable because it uses a
> *word* rather than unsearchable symbols to define a structure.
>
> Also, I get that arrays not actually implemented as such behind the
> scenes but you simply can't deprecate an estimated 70 million lines of
> code globally (and that's the code you can see, not including internal
> software everywhere).  "Hi, for PHP 8, we are going to fill your hard
> drives via your application logs with deprecation warnings and crash
> your servers.  Have fun sorting that mess out!"
>
> Finally, barring a serious security vulnerability, keywords should be
> viewed as permanent fixtures of the language.  They can't be deprecated.
>   That's why there are so few keywords.  Far too much userland code will
> unnecessarily break.  You suggest deprecating 'array' but not
> 'enddeclare', 'endfor', 'endforeach', 'endif', 'endswitch', 'endwhile'.
> All of those have alternative "shortcuts" but you didn't mention
> deprecating those keywords even though there is far less usage compared
> to 'array'.
>

In all honnesty, those keywords didn't even cross my mind because I have
so rarely seen them.
Now if people want to discuss if those should be deprecated or not I'm all
for it
But from the general vibe I get this seems like it is not going to go
anywhere.


Best regards

George P. Banyard

--0000000000002a17e605802362d3--