Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103792
MIME-Version: 1.0
References: <CAFPFaM+cEa2xFDqvkLQk=Qht3KdcGUCBaCj6JcuQxqLmjnf9Pw@mail.gmail.com>
 <HE1P189MB0492D67D4A6715B4FBF72F1A91990@HE1P189MB0492.EURP189.PROD.OUTLOOK.COM>
In-Reply-To: <HE1P189MB0492D67D4A6715B4FBF72F1A91990@HE1P189MB0492.EURP189.PROD.OUTLOOK.COM>
Date: Wed, 23 Jan 2019 12:14:44 +0200
Message-ID: <CAL0xaBH3OioafrCDMaRaHB1Z_Or81cLWZSrdL2LkW_SBTCG-3Q@mail.gmail.com>
To: Jani Ollikainen <jani.ollikainen@valve.fi>
Cc: Girgias <george.banyard@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000078328305801d5e88"
Subject: Re: [PHP-DEV] Deprecation ideas for PHP 8
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--00000000000078328305801d5e88
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=D1=81=D1=80, 23 =D1=8F=D0=BD=D0=B2. 2019 =D0=B3. =D0=B2 12:04, Jani Ollika=
inen <jani.ollikainen@valve.fi>:

> Hi,
>
> The arguments why to deprecate didn't seem much more than, this maybe
> could be deprecated. I think there should usually be some
> benefits of deprecating, otherwise why not just leave it as it is?
>
> But some comments that I didn't notice in others.
>
> >    - php_uname (use PHP_OS constant)
>
> PHP_OS is php_uname('s'), how about rest:
>
> mode
>
>     mode is a single character that defines what information is returned:
>
>         'a': This is the default. Contains all modes in the sequence "s n
> r v m".
>         's': Operating system name. eg. FreeBSD.
>         'n': Host name. eg. localhost.example.com.
>         'r': Release name. eg. 5.1.2-RELEASE.
>         'v': Version information. Varies a lot between operating systems.
>         'm': Machine type. eg. i386.
>
>
> > 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
> same
> >   class must not be used)
>
> Both these have $allow_string
>
> > Function handling functions:
> >   - call_user_func (invoke directly)
>
> Yes, they give a little performance hit, but I still kind of like them.
> Like if we think the following, I think I would prefer call_user_func for
> syntax.
>
> class PREA {
>         public function AB() {
>                 echo "HELLO".PHP_EOL;
>         }
>         public static function AC() {
>                 echo "HELLOSTATIC".PHP_EOL;
>         }
> }
>
> $prefix=3D'PRE';
> $class=3D'A';
> $method=3D'B';
> $static=3D'C';
>
> $classVar=3D$prefix.$class;
>
> (new $classVar())->{$class.$method}();
> ($prefix.$class)::{$class.$static}();
>
> call_user_func(array(new $classVar(), $class.$method));
> call_user_func($prefix.$class.'::'.$class.$static);
>
> And for the rest. Yes, there is another way of doing it, but is that
> really enough for deprecating something?
>
> > Setting var type (can use variable casting nowadays):
>
> Yes, we can cast, but is this reason for make someone to go through all
> the old code and do
> -$var =3D intval($var);
> +$var =3D (int) $var;
>
>
>
Hello to everyone.

As a userland dev, I have to agree with Jani here - when I looked through
the list of functions I had question marks all over the place about the
`call_user_func*` family. Sure, closures are nice, but as demonstrated
above they are not always the best-looking code and `call_user_func*`
family has it's used. Maybe I'm just not using this functionality that
much, so it seems like it's out of nowhere to deprecate/remove these for me=
.

is_writeable vs is_writable - the more you know *music* :)


--=20
Arv=C4=ABds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

--00000000000078328305801d5e88--