Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103779
MIME-Version: 1.0
Date: Tue, 22 Jan 2019 21:34:33 +0100
Message-ID: <CAFPFaM+cEa2xFDqvkLQk=Qht3KdcGUCBaCj6JcuQxqLmjnf9Pw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000835b02058011e889"
Subject: [PHP-DEV] Deprecation ideas for PHP 8
From: george.banyard@gmail.com (Girgias)

--000000000000835b02058011e889
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 sam=
e
   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 functions
   (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 type
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 float
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 probably
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 feel
this covers
already a large portion.


Best regards

George P. Banyard

--000000000000835b02058011e889--