Re: [PHP-DEV] Deprecation ideas for PHP 8

Totally agree with this. The new and old can exist both. We should be open to change. On Thu, 31 Jan 2019, 11:53 Benjamin Morel Please forgive my stubborness, too. I fail to see how WordPress supporting > PHP versions that have been EOL for YEARS can be of any help to the > community? These

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Fri, 1 Feb 2019 at 09:47, Yasuo Ohgaki wrote: > Aliases may stay defined 10, 20 years or even forever for POSIX(IEEE) > names. > So there wouldn't be compatibility issues for CODING_STANDARD names. > I think this would be the worst of both worlds. We would have to permanently document two

Re: [PHP-DEV] Deprecation ideas for PHP 8

Den fre. 1. feb. 2019 kl. 12.34 skrev Benjamin Morel : > You have a point here. Couldn't we add a "deprecated log" feature, that > would log each deprecated function only once? At least we could leave an > app running for some time, and get a curated list of deprecated features > from the

Re: [PHP-DEV] Deprecation ideas for PHP 8

> Deprecation notices won't change people's *desire* to change their code. If you raised a deprecation notice for every call to, say "htmlspecialchars", the only result would be people turning off deprecation notices, and missing more important deprecations. You have a point here. Couldn't we

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Thu, 31 Jan 2019 at 22:39, Benjamin Morel wrote: >> What if people's muscle memory, their coding standards, their need for progressive compatibility, their tools, the tutorials they follow, the code snippets they copy, all make it easier to just keep using the old names? >> Then our

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Thu, Jan 31, 2019 at 7:30 PM Rowan Collins wrote: > On Thu, 31 Jan 2019 at 07:34, Peter Kokot wrote: > > > Sorry, I didn't put my words correctly here. Not inconsistency. > > Inconsistency is a fact, yes. I've meant the incapability of doing > > something to fix this inconsistency. And it is

Re: [PHP-DEV] Deprecation ideas for PHP 8

> The problem comes if the share using the old names *doesn't* decline enough (and how would we even know?). We can't survey private projects, but we can run automated analysis tools on a large number of open-source projects available on GitHub, and compile statistics from them. I'd be happy to

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Thu, 31 Jan 2019 at 10:53, Benjamin Morel wrote: > Please forgive my stubborness, too. I fail to see how WordPress supporting > PHP versions that have been EOL for YEARS can be of any help to the > community? > I agree, it probably doesn't help the community; but it happens, both in open

Re: [PHP-DEV] Deprecation ideas for PHP 8

On 31.01.2019 at 08:34, Peter Kokot wrote: > The RFC: Consistent function names [1] shows the magnitude of this. I > don't think every function listed there needs a change so it can be > greatly reduced. But still this can be done in several years to 10 > years or so (measuring over the thumb). >

Re: [PHP-DEV] Deprecation ideas for PHP 8

Please forgive my stubborness, too. I fail to see how WordPress supporting PHP versions that have been EOL for YEARS can be of any help to the community? These versions may have unpatched security holes, and encouraging users to keep using them is a disfavour to the community IMO, which can only

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Thu, 31 Jan 2019 at 07:34, Peter Kokot wrote: > Sorry, I didn't put my words correctly here. Not inconsistency. > Inconsistency is a fact, yes. I've meant the incapability of doing > something to fix this inconsistency. And it is becoming some sort of > stubborn belief and less and less

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Wed, 30 Jan 2019 at 20:51, Rowan Collins wrote: > > On 30/01/2019 17:28, Peter Kokot wrote: > > This now also means that PHP is making its inconsistency a fact > > > The inconsistency IS a fact, and has been for more than 20 years. This > isn't some new policy, banning something that used to

Re: [PHP-DEV] Deprecation ideas for PHP 8

On 30/01/2019 17:28, Peter Kokot wrote: This now also means that PHP is making its inconsistency a fact The inconsistency IS a fact, and has been for more than 20 years. This isn't some new policy, banning something that used to be possible, it's a summary of something that's been discussed

Re: [PHP-DEV] Deprecation ideas for PHP 8

Hello, On Tue, 22 Jan 2019 at 23:40, Rowan Collins wrote: > > On 22/01/2019 21:27, Midori Koçak wrote: > > Can we also add strange function names without any naming conventions to > > this list > > In short, no. I wish we had an FAQ where we could avoid recapping the > arguments around this, but

Re: [PHP-DEV] Deprecation ideas for PHP 8

> On 29 Jan 2019, at 07:13, Girgias wrote: > > On Thu, 24 Jan 2019 at 01:25, Dan Ackroyd wrote: > >> On Wed, 23 Jan 2019 at 17:25, Girgias wrote: >> >>> I understand the rationale for functional programming, may I ask >>> in your opinion should PHP have built-in functions for arithmetic

Re: [PHP-DEV] Deprecation ideas for PHP 8

> > And then there is *array_multisort* a function which has a signature which > isn't even possible in userland code. > (https://secure.php.net/manual/en/function.array-multisort.php > ). > Other than the fact that this function's

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Thu, 24 Jan 2019 at 01:25, Dan Ackroyd wrote: > On Wed, 23 Jan 2019 at 17:25, Girgias wrote: > > > 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

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Wed, 23 Jan 2019 at 17:25, Girgias wrote: > 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? No, but only I'd much

Re: [PHP-DEV] Deprecation ideas for PHP 8

Hi George, Iiuc, the problem you're trying to solve is that PHP offers too many ways to do the same thing and if there were fewer then PHP code would be easier to write, read and maintain. Differences in code that make no difference to the compiler are differences in style. The

Re: [PHP-DEV] Deprecation ideas for PHP 8

On 23.01.2019 at 18:30, Rowan Collins wrote: > On Wed, 23 Jan 2019 at 17:25, Girgias wrote: > >> 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

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Wed, 23 Jan 2019 at 18:30, Rowan Collins wrote: > On Wed, 23 Jan 2019 at 17:25, Girgias wrote: > > > 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

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Wed, 23 Jan 2019 at 17:25, Girgias wrote: > 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? > There was a

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Wed, 23 Jan 2019 at 16:23, Dan Ackroyd wrote: > On Tue, 22 Jan 2019 at 20:34, Girgias 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

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Wed, 23 Jan 2019 at 16:37, Benjamin Morel wrote: > > 2.78 million vs. 5.1 million* code references. > > 1.54 million results. > > 10 million results. Broad, active usage. > > ... > > I would not in any way base deprecation decisions on current usage > statistics. If there are several ways to

Re: [PHP-DEV] Deprecation ideas for PHP 8

> 2.78 million vs. 5.1 million* code references. > 1.54 million results. > 10 million results. Broad, active usage. > ... I would not in any way base deprecation decisions on current usage statistics. If there are several ways to do something, and one is clearly better than the others (naming

Re: [PHP-DEV] Deprecation ideas for PHP 8

On 1/22/2019 1:34 PM, Girgias 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

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Tue, Jan 22, 2019 at 1:35 PM Girgias 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

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Tue, 22 Jan 2019 at 20:34, Girgias 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

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Wed, 23 Jan 2019 at 15:43, Claude Pache wrote: > So, since you didn’t see, here are some practical usages of settype(): > > function foo($bar) { > // $bar is supposed to be either a string, or a list of strings > settype($bar, 'array'); > // ... > } > > function qux($id) { >

Re: [PHP-DEV] Deprecation ideas for PHP 8

> Le 23 janv. 2019 à 14:19, Girgias a écrit : > > > > On Wed, 23 Jan 2019 at 09:19, Claude Pache wrote: > >> >>> - settype >> >> AFAICS, there is no easy replacement for settype(). If the second argument >> is a string literal, you can use type coercion + assignment at the price of >>

Re: [PHP-DEV] Deprecation ideas for PHP 8

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

ср, 23 янв. 2019 г. в 12:04, Jani Ollikainen : > 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

RE: [PHP-DEV] Deprecation ideas for PHP 8

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)

Re: [PHP-DEV] Deprecation ideas for PHP 8

> - settype AFAICS, there is no easy replacement for settype(). If the second argument 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

Re: [PHP-DEV] Deprecation ideas for PHP 8

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? - intval (for arbitrary base change there exists the math function base_convert) I've seen and myself

Re: [PHP-DEV] Deprecation ideas for PHP 8

On 22/01/2019 21:27, Midori Koçak wrote: Can we also add strange function names without any naming conventions to this list In short, no. I wish we had an FAQ where we could avoid recapping the arguments around this, but it has come up many times, and the conclusion has always been that it's

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Tue, 22 Jan 2019 at 23:28, Yasuo Ohgaki wrote: > On Wed, Jan 23, 2019 at 7:08 AM Girgias wrote: > > > On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki wrote: > > > >> Hi Girgias > >> > >> It seems good list in general. > >> There would not be issues marking them as deprecated. > >> "Deprecation"

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Wed, Jan 23, 2019 at 7:08 AM Girgias wrote: > On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki wrote: > >> Hi Girgias >> >> It seems good list in general. >> There would not be issues marking them as deprecated. >> "Deprecation" means "Soft deprecation", correct? >> >> Removing these aliases from

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki wrote: > Hi Girgias > > It seems good list in general. > There would not be issues marking them as deprecated. > "Deprecation" means "Soft deprecation", correct? > > Removing these aliases from PHP 8 is not good idea. > Aliases should be removed when

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Wed, Jan 23, 2019 at 6:28 AM Midori Koçak wrote: > Can we also add strange function names without any naming conventions to > this list? Without undersore: strcspn, With underscore: str_repeat, chain > of abrevs: strnatcasecmp. Similar namings do exist for array functions > either. >

Re: [PHP-DEV] Deprecation ideas for PHP 8

Hi Girgias It seems good list in general. There would not be issues marking them as deprecated. "Deprecation" means "Soft deprecation", correct? Removing these aliases from PHP 8 is not good idea. Aliases should be removed when nobody cares about these aliases. For example, pg_loopen()/etc were

Re: [PHP-DEV] Deprecation ideas for PHP 8

Can we also add strange function names without any naming conventions to this list? Without undersore: strcspn, With underscore: str_repeat, chain of abrevs: strnatcasecmp. Similar namings do exist for array functions either. Cheers, Midori On Tue, 22 Jan 2019 at 22:22, Girgias wrote: > On

Re: [PHP-DEV] Deprecation ideas for PHP 8

On Tue, 22 Jan 2019 at 21:48, Stephen Reay wrote: > > > On 23 Jan 2019, at 03:34, Girgias wrote: > > 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

Re: [PHP-DEV] Deprecation ideas for PHP 8

> On 23 Jan 2019, at 03:34, Girgias 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

[PHP-DEV] Deprecation ideas for PHP 8

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