Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103795 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91403 invoked from network); 23 Jan 2019 16:41:54 -0000 Received: from unknown (HELO mail-vs1-f46.google.com) (209.85.217.46) by pb1.pair.com with SMTP; 23 Jan 2019 16:41:54 -0000 Received: by mail-vs1-f46.google.com with SMTP id n13so1268547vsk.4 for ; Wed, 23 Jan 2019 05:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gdQwJQjc4jkN+lwEwWiHjG+tRpsIHo3Xg/0pR4ibasg=; b=QVuIh6Y9Tr7twpmHOvjAJcFYp2d2KvVKW2o/adDFcO6I0d6vaciWgJnAEBEOcbUeIg SSKrnBVF6kxVnIId5+f4mulnBRmNN+XtyAzKCU+aQ6KKjGIExTu/c8H/awfJu852NDun dxFOvFn3oHKaW5xPgOeN68xHQTtNCAYi2d5Ho/U2Y0Swi8XwzLoHtt0CN47N4WJ+SPDc pQ5zpR1XoqTVXJlOVLdSqXWjlVGsvnCTiVazh1y+/hKvANC6pUiNGEdXZ6y7lM7FhK7u RwlzUxeNq+R/JQY91V/RcUoQbclQWnFHrnaGoJLnZOXLd4s2K6cmHhzAEscI772BlaRQ Yz/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gdQwJQjc4jkN+lwEwWiHjG+tRpsIHo3Xg/0pR4ibasg=; b=Q7Jp3YN/SBjKqLOGzFYxNzu3P2fqfITsHfaSRiKubQ9YceimyICwenUdMjrLO7H8WI 8sCyhoym7Yucu9z4YlK4q4Ywo8Y8wXF/JBA6aAk8+SQhQJGyKbpDe0hh1EtMTyYUb2WL iZdiZhKPQGaNoN/TgithyDAsp+wlzsJVvlquKw2gliWRvskWJeiV9wt2PX00WMVl5w1t dmFfnMyFf4Kox3eB5swsl+lofkp+CfSQNmKxSGtBE1u+XP4Nj0j/BX0z+cUE/ABWiMFy Z/KBLVWFISCvUtyh/bV3iB+jMDHeaUHltl+mm68XSfPZLh4jKm5DasCBEmWATuPTvwGu AyuQ== X-Gm-Message-State: AJcUukdJeTXuNTSiiDvcvQimDVs7SC3FUkQ24ZLBS9AgXfyB2+k6k+Ph npvuJ2PyUvvqMNPUkeQxwMogodvJ4ij8fxgMk3w= X-Google-Smtp-Source: ALg8bN4Evtw4kmX+TRw2dFRq0fy1gv0bXmdWtP/J2phdl7hH+2tve4PWfOIcwTPM2xqw/JtWMukWIXeKtPsRaAQkkRQ= X-Received: by 2002:a67:6d42:: with SMTP id i63mr857594vsc.158.1548249587770; Wed, 23 Jan 2019 05:19:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 23 Jan 2019 14:19:33 +0100 Message-ID: To: Arvids Godjuks Cc: Jani Ollikainen , "internals@lists.php.net" Content-Type: multipart/alternative; boundary="000000000000b3e9da05801ff293" Subject: Re: [PHP-DEV] Deprecation ideas for PHP 8 From: george.banyard@gmail.com (Girgias) --000000000000b3e9da05801ff293 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 23 Jan 2019 at 09:02, Markus Fischer wrote: > Hi, > > On 22.01.19 21:34, Girgias wrote: > > - phpversion (use PHP_VERSION constant) > > The function takes an optional argument `string $extension`, what is the > replacement for that? > Didn 't realise not all of the extensions have a version constant. > > - intval (for arbitrary base change there exists the math function > > base_convert) > > I've seen and myself use the following construct a lot to "quickly" > convert data within an array: > > $data =3D array_map('intval', $data); > > It's really practical because I don't have to write a (more verbose) > closure. > > I'd argue this applies to the other `*val` calls too. > Seems like this is one of the only practical usages but a quite important one that I did not consider. > - join (alias of implode) > > > > Old signatures: > > > > - implode (historical signature) > > Is there a correlation here why you mention the alias join and the > actual function implode? I hope you would want to leave either in the > language :-) > Completly unrelated, join is an alias whereas the old implode signature I'm talking about is the implode(array $pieces, string $glue =3D '') which is n= ot recommended compared to the recommended signature implode(string $glue, array $pieces) which mimics the explode signature. I do want to keep implode() just deprecate the historical signature. On Wed, 23 Jan 2019 at 09:19, Claude Pache wrote: > > > - settype > > AFAICS, there is no easy replacement for settype(). If the second argumen= t > is a string literal, you can use type coercion + assignment at the price = of > duplicating the occurrence of the first argument. If the second argument = is > not known at compile time, you have to resort to a switch statement or > something similar. > I did not consider that someone might want to set the type of a variable at runtime because I can not see any pratical usages for that, imho you change a variable type into another one because you want to work with that specific type. But it basically boils down to the same issue as with gettype that without it you need to do a switch statement to get something similar. > > > - deprecate array function creation (array()) > > Here, I was really wondering why you didn=E2=80=99t mention function-like > destructuring as well (list()). (Not that I think it is a good idea.) > Thanks for catching that oversight, been a while since I haven't used list(= ) And I can totally see why you wouldn't think it's a good idea I just feel a major version change is an approriate time to bring such controversial issues to the table. On Wed, 23 Jan 2019 at 11:04, Jani Ollikainen wrote: > 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? > My reasonning for theses deprecation is to get rid of some of the "clutter" within the PHP core, as in I don't see the benefit of having multiple aliases nor functions which can be achieved with some more modern constructs. > 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. > gethostname() can retrive this information > 'r': Release name. eg. 5.1.2-RELEASE. > PHP_EXTRA_VERSION > 'v': Version information. Varies a lot between operating systems. > 'm': Machine type. eg. i386. > For these two doesn't seem like I can find something equivalent > Classes/Objects functions: > > - is_a (use instanceof operator) > intanceof accepts a string as secodn operand but it needs to be within a variable however contrary to is_subclass_of, is_a does not accept a string as first parameter which makes is_a completly unnecessary imho. See: https://3v4l.org/hn1Ao > - 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) > I do acknoledge this one has a usage as per one of my previous replies. > > 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); > Going from the fact that you are using call_user_func instead of forward_static_call to make a static call I feel this shows how call_user_func can be abused comapred to just doing a direct call. But in the end this maybe boils down to personal preferences as I find call_user_fun horrendous as a construction > 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; > I feel with a whole major version to be able to adapt that seems like a reseonable drawback to have - imho - better code. On Wed, 23 Jan 2019 at 11:15, Arvids Godjuks wrote: > 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. > I feel like not a lot of people are aware that you can replace call_user_func with the splat operator, and as said just before imho closures are nicer than call_user_fun* I just want to finish and say that thanks for the constructive feedback and different opinions that you all provided. Best regards George P. Banyard --000000000000b3e9da05801ff293--