Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103804
MIME-Version: 1.0
References: <CAFPFaM+cEa2xFDqvkLQk=Qht3KdcGUCBaCj6JcuQxqLmjnf9Pw@mail.gmail.com>
In-Reply-To: <CAFPFaM+cEa2xFDqvkLQk=Qht3KdcGUCBaCj6JcuQxqLmjnf9Pw@mail.gmail.com>
Date: Wed, 23 Jan 2019 08:51:00 -0700
Message-ID: <CAFMT4NqQ_yu=Z12wbRK1MYv1Z=Dy+SLdUX5mwF2BxHT0XO6D6Q@mail.gmail.com>
To: Girgias <george.banyard@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Deprecation ideas for PHP 8
From: levim@php.net (Levi Morrison)

On Tue, Jan 22, 2019 at 1:35 PM Girgias <george.banyard@gmail.com> wrote:
>
> Greetings PHP internals,
> After skimming through the PHP documentation, I came up with a list of
> functions which seem
> reasonable to deprecate as of PHP 8 and I would like to gather some
> opinions from Internals.
> If this seems like it's too early or should be in an RFC draft please let
> me know and in case it
> needs an RFC may I have Karma to do so.
> Without further ado here is the list I compiled:
>
> PHP Info/Option functions:
>
>    - php_sapi_name (use PHP_SAPI constant)
>    - phpversion (use PHP_VERSION constant)
>    - php_uname (use PHP_OS constant)
>
> Classes/Objects functions:
>
>    - is_a (use instanceof operator)
>    - is_subclass_of (not exactly what it's purpose is but the instanceof
>    operator SHOULD be a valid equivalence with another condition if the s=
ame
>    class must not be used)
>
> 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 function=
s
>    (splat operator))
>    - func_get_args (same reason as func_get_arg)
>    - func_num_args (same reason as func_get_arg)
>
> Variable handling functions:
> Aliases:
>
>    - is_double
>    - is_integer
>    - is_long
>    - is_real (already in the deprecation draft for PHP 7.4)
>
> Setting var type (can use variable casting nowadays):
>
>    - boolval
>    - doubleval
>    - floatval
>    - intval (for arbitrary base change there exists the math function
>    base_convert)
>    - settype
>    - strval
>    - gettype (more on this later [1])
>
> String functions aliases:
>
>    - chop (alias of rtrim)
>    - join (alias of implode)
>    - strchr (alias of strstr)
>
> Maths functions aliases:
>
>    - getrandmax
>    - rand (use mt_rand instead)
>    - srand (alias of mt_srand as of PHP 7.1)
>
> Filesystem aliases:
>
>    - diskfreespace =E2=80=94 Alias of disk_free_space
>    - fputs =E2=80=94  Alias of fwrite
>    - is_writeable =E2=80=94 Alias of is_writable
>    - set_file_buffer =E2=80=94 Alias of stream_set_write_buffer
>
> Old signatures:
>
>    - implode (historical signature)
>
> Controversial idea:
>
>    - deprecate array function creation (array())
>
>
> [1] About gettype:
> The gettype function is really convenient as it can easily provide the ty=
pe
> of a variable without
> needed to use a bunch of conditional checks, it can even as of PHP 7.2
> signal if a resource
> has been closed.
> However, it still returns "double" for a float due to historical reasons
> and it seems quite
> complicated to change how it operates currently.
> I have thought of two possible ideas which would allow PHP to return floa=
t
> instead of double:
>
> First, create a new reflection class ReflectionVar:
> This feels even to me like a bit of an overkill more so that something
> simple (a unique function
> call) would require an object instantiation. But it can allow some
> extensions such as the
> Reflection for Reference RFC proposed by nikic (c.f.
> https://wiki.php.net/rfc/reference_reflection)
>
> Second, create a new function get_var_type($mixed):
> This would behave exactly the same as the current implementation with the
> one difference that
> it would return 'float' instead of 'double'. This new function name would
> be more consistent with how the other functions are named (namely
> get_resource_type).
> This implementation has the benefit of keeping it simple but will probabl=
y
> duplicate code within the engine.
>
>
> Just to remind these are only ideas and feedback is wholeheartedly
> welcomed. I also probably
> missed some more functions which could be deprecated as of PHP 8 but I fe=
el
> this covers
> already a large portion.
>
>
> Best regards
>
> George P. Banyard

I see no reason to get rid of aliases, which comprises most of your list.